Search and Top Navigation
#7065 open bug ()
Opened March 04, 2011 05:25PM UTC
Last modified February 06, 2018 03:26PM UTC
Sortable: Connected sortables interact poorly with overflow: scroll
Reported by: | jdmarshall | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 2.0.0 |
Component: | ui.sortable | Version: | 1.8.9 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
This ticket describes a failure mode with Sortable lists, and how dropping an item into the final position on the list doesn't work as expected.
Repro steps:
- Create 3 equal height scrollable divs. Style the placeholder so you can see it.
- Overfill the first one (force scrollbar) by a factor of >2
- Overfill the last one by a factor of >2
- Condition 1:
- try to drag an item from the 3rd list to the last position on the middle list.
- Observe that the placeholder doesn't go into the middle list.
- Condition 2:
- Scroll the last div to the bottom
- Try to drag an item from the first list to the last position on the middle list.
Workarounds:
- Reposition the lists
- Drag into the 2nd to last position, then rearrange the list (move the last element where you wanted it).
- Turn on placeholder highlighting. There is actually a very very narrow area below the last element (in the margin perhaps?) where drags are accepted, and the placeholder hint helps you find it.
Attachments (0)
Change History (13)
Changed March 08, 2011 06:45PM UTC by comment:1
Changed March 09, 2011 06:41PM UTC by comment:2
Is anyone working on this? Just wanna know because I'm delaying the release of a website because of this bug.
Changed March 09, 2011 06:56PM UTC by comment:3
No; sortable will be rewritten for the 2.0 release.
Changed March 10, 2011 01:25AM UTC by comment:4
Okay, then how about some help with a workaround? I'm in the same boat. Originally this was supposed to be fixed in 1.9 so it wasn't that big of a deal. Now it's slated for 2.0. If that remains true until release date, that's a long way off.
This bug makes sortable unworkable for the majority of non-trivial use cases. How would you use it without running afoul of this issue?
Changed March 10, 2011 02:17PM UTC by comment:5
The state of the code for sortable today leads to issues that are too difficult to debug and fix and consequently it has been stable for many years with very few changes. Even the changes that have been made were with risk because the code, for as stable as it is, is not very robust. Our solution, given limited resources and no one able and willing to work on the existing codebase, is to rewrite it during this year.
Changed March 14, 2011 06:35AM UTC by comment:6
I've started working on my own version which now already works for a few purposes without this overflow issue. I'm using your draggable methods and thinking of making it as complete as the original sortable. Is there anything important for me to have in mind if you guys want to use it as your new version? I wouldn't mind making a little contribution to the library.
Changed April 11, 2011 05:24PM UTC by comment:7
Looking at this a bit more, it seems like the main problem is that drop locations are determined by polling the entire list of sortable items looking for the 1st one that overlaps the dragged item. 'Overlaps' here meaning that a 2d collision test is done vs the absolute position of the item.
In addition to being hugely inefficient, it's wrong when one of the items is obscured by a scroll pane.
There are at least two solutions to this: One would be to search for the sortable target first, and then only do the item shuffling logic on those elements. The other would be to sort all of the items by position, return all of the items that overlap the dragged item, and then make a decision about which one is the most likely candidate.
I'm hoping the new version doesn't rely on finding the location of every item on the page at the beginning of every drag event, so it seems like sorting the items is probably the wrong solution.
As to a workaround for this bug: I think I may have identified one, but I still need to implement it and write it up.
Changed June 27, 2011 05:38PM UTC by comment:8
The code does seem to favor finding any container other than the current one to put the element into. The good news/bad news of this situation is that the behavior is pretty consistent: Two overlapping lists, it will nearly always drop in the 'wrong one'.
I'll reiterate my assertion that a topological search should be better here. That is: first look for all containers that overlap the dragged item, then pick the spot to put it, instead of the other way around. In the degenerate case of only one list, this is ever so slightly slower, but the complexity is so low that nobody will ever notice.
Changed July 19, 2011 09:00PM UTC by comment:9
This is my workaround.
_intersectsWithPointer: function(item) { if (this._intersectsWith(item.instance.containerCache)) { return this._oldIntersectsWithPointer(item); } return false; }
Changed October 11, 2012 02:55PM UTC by comment:10
milestone: | 1.9.0 → 2.0.0 |
---|
Changed November 08, 2012 03:54AM UTC by comment:11
#8039 is a duplicate of this ticket.
Changed November 08, 2012 03:58AM UTC by comment:12
status: | new → open |
---|---|
summary: | Connected Sortables interact poorly with overflow: scroll → Sortable: Connected sortables interact poorly with overflow: scroll |
Test case from @alecs in #8039 updated for 1.9.1 - http://jsfiddle.net/tj_vantoll/Wzrud/.
Changed February 06, 2018 03:26PM UTC by comment:13
Any updates or workarounds available for this bug yet?
#7082 is a duplicate of this ticket.