Skip to main content

Search and Top Navigation

#5620 closed bug (wontfix)

Opened May 17, 2010 03:43PM UTC

Closed November 08, 2012 01:41AM UTC

Last modified March 12, 2013 08:46PM UTC

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 (6)

Changed May 17, 2010 03:48PM UTC by marcusf comment:1

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!

Changed May 24, 2010 06:14PM UTC by marcusf comment:2

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.

Changed June 02, 2010 12:27PM UTC by marcusf comment:3

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).

Changed October 11, 2012 09:07PM UTC by scottgonzalez comment:4

milestone: TBD2.0.0

Changed November 08, 2012 01:41AM UTC by mikesherov comment:5

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: 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!

Changed March 12, 2013 08:46PM UTC by dcarrith comment:6

@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.