Metadata
- Source
- FLUID-152
- Type
- Bug
- Priority
- Major
- Status
- Closed
- Resolution
- Incomplete
- Assignee
- Jonathan Hung
- Reporter
- Michelle D'Souza
- Created
2007-12-18T16:55:06.000-0500 - Updated
2008-07-11T14:36:43.000-0400 - Versions
- N/A
- Fixed Versions
- N/A
- Component
-
- Image Reorderer
Description
To recreate:
1. Pick up a thumbnail from the first row.
2. Drag it into position so that the drop marker appears after the first item in the second row and the mouse pointer is hovering over the first item in the second row.
3. Drop the thumbnail.
4. Notice that it was been placed in front of the first item in the second row which is at the end of the first row.
Comments
-
Michelle D'Souza commented
2007-12-18T16:58:32.000-0500 I think this behaviour was introduced while fixing Fluid-100
-
Joseph Scheuhammer commented
2007-12-20T16:55:28.000-0500 During testing of the fix for FLUID-146, I noticed that this bug (FLUID-152) happens only when dragging on whitespace (in a lightbox thumbnail). If dragging is initiated on the image or the link text, then the drop behaviour is correct.
-
Jonathan Hung commented
2008-01-31T16:23:11.000-0500 A variation on this problem:
1. pick up 2nd thumbnail from second row using white space WITH the mouse pointer near the right-edge of the thumbnail box
2. drag to 1st row between the 2nd last and last item WITH the mouse pointer hovering over last item
3. release
4. dragged item appears as first item on 2nd row instead of being last item on the first row. -
Jonathan Hung commented
2008-02-01T15:33:35.000-0500 I did some investigating and have some more information why this bug is happening.
isMouseBefore() is returning a bad value for this edge case. You can see this clearly by placing the following Firebug output just before the return (evt.clientX < mid); statement:
console.log ("evt.clientX = " + evt.clientX + ", mid = " + mid);
Following the directions in my comment above; as you watch the console output, you will see that the "mid" values are all correct while dragging with the mouse. But once releasing the mouse button, the mid value changes drastically thus resulting in an erroneous item move.
On closer examination, jQuery (droppableEl).offset().left is not returning a value we expect after the mouse has been released and mouseMoveItem() is called.
-
Jonathan Hung commented
2008-02-05T13:29:58.000-0500 Did some digging. It appears that drop() was being called twice during this particular mouse action. Further investigation revealed that this is indeed a bug in jQuery UI 1.0. http://dev.jquery.com/ticket/1547
Following bstar's temporary fix documented in the #1547 bug report, this problem in FLUID-152 appears to be fixed.
I will commit both a patch and a modified version of ui.droppable.js to our SVN and document appropriately.
When jQueryUI v1.5 is available, we should check to see that #1547 is fixed without our patch and remove our patch as necessary.