#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: |
Description
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)
Change History (8)
Changed 13 years ago by
Attachment: | testcase.html added |
---|
Changed 13 years ago by
Attachment: | testcase-vertical-limited-sortable.zip added |
---|
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
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: http://github.com/marcusfrodin/jquery-ui/commit/dc5c4b3b48eeac1e5931fb5496f5a46f3f24bd7d -- 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
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
Milestone: | TBD → 2.0.0 |
---|
comment:5 Changed 10 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Thanks for contributing! I know it's been a while and the pull stagnated, but I've reproduced the issue here: http://jsfiddle.net/P9bRc/ 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
@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.
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.
Thanks!