Opened 13 years ago

Closed 10 years ago

Last modified 10 years ago

#5620 closed bug (wontfix)

Sortable along y-axis with parent containment fails to put large item at the bottom of list when dragging

Reported by: marcusf Owned by:
Priority: minor Milestone: 2.0.0
Component: ui.sortable Version: 1.8.1
Keywords: Cc:
Blocked by: Blocking:


See attached test case (the zip file is just the test case together with the jquery and jquery-ui used, 1.4.2 and 1.8.1 respectively).

How to reproduce: Grab item "Very long text …" and drag to bottom

Expected behavior: Item ends up at the bottom

Behavior seen: Item snaps back to original position

Attachments (2)

testcase.html (1.0 KB) - added by marcusf 13 years ago. (74.0 KB) - added by marcusf 13 years ago.

Download all attachments as: .zip

Change History (8)

Changed 13 years ago by marcusf

Attachment: testcase.html added

Changed 13 years ago by marcusf

comment:1 Changed 13 years ago by marcusf

I should add, if I did something wrong I'd love a pointer in the right direction.

Also, I've tried this both in Safari 4 a recent Webkit Nightly and Firefox 3.0.


comment:2 Changed 13 years ago by marcusf

I've tried to come up with a solution to this myself.

Our product currently uses an aging drag and drop for lists called "toolman". It solves this problem by allowing items to slide a few px outside their containment when dragging. I've tried to reproduce this behaviour here: -- I introduce an option called containmentElasticity (which is a really poor name, and I'm open to suggestions :))

It works in our case, but probably breaks in the general case since I'm not very well versed in the jQuery UI codebase.

comment:3 Changed 13 years ago by marcusf

Hi. there's been no progress on this at all since I sent a pull request nine days ago. Even if this is a non-issue and the code is terrible, I'd love to hear something. It's kinda important for us. (The reason I didn't set a high priority on it is that it seems rude on another projects bug tracker).

comment:4 Changed 10 years ago by Scott González

Milestone: TBD2.0.0

comment:5 Changed 10 years ago by mikesherov

Resolution: wontfix
Status: newclosed

Thanks for contributing! I know it's been a while and the pull stagnated, but I've reproduced the issue here: and it seems as if this is intended behavior. I'm going to close this as wontfix, but there are plenty of bug fixes to work on if you're interested!

comment:6 Changed 10 years ago by dcarrith

@mikesherov - it seems to me that this is an issue with the "tolerance" implementation (specifically, the "intersect" method of "tolerance" - which happens to be the default). I would expect the big element to cause a re-arrangement as soon as one of the edges crosses the middle of the smaller element. However, it seems that the implementation of "intersect" is more of a hybrid of the other option "pointer" (which, by the way, might be what the OP is looking for). By that, I mean, whether or not the dragging of the big element causes the re-arrangement of the small items depends on where the mouse pointer was when the big element was grabbed for dragging. If I start dragging the big element at the very bottom edge of it, and drag it down, then I can get the #5 small element to re-arrange and the big element can then be dropped as the last element. Similarly, if I grab the big element at the very top edge, I can then drag it all the way up to the top and drop it as the first element. However, if I then grab the big element from the very top edge and try to drag it down, I can only get element 1 to re-arrange. I don't see how this can be intended behavior.

Note: See TracTickets for help on using tickets.