Sortable: Connected sortables interact poorly with overflow: scroll

[jdmarshall]

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.

[Scott González]

#7082 is a duplicate of this ticket.

[peterthegreat]

Is anyone working on this? Just wanna know because I'm delaying the release of a website because of this bug.

[Scott González]

No; sortable will be rewritten for the 2.0 release.

[jdmarshall]

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?

[rdworth]

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.

[peterthegreat]

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.

[jdmarshall]

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.

[jdmarshall]

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.

[jdmarshall]

This is my workaround.

       _intersectsWithPointer: function(item) {
          if (this._intersectsWith(item.instance.containerCache)) {
             return this._oldIntersectsWithPointer(item);
          }

          return false;
       }

[tj.vantoll]

#8039 is a duplicate of this ticket.

[tj.vantoll]

Test case from @alecs in #8039 updated for 1.9.1 - ​http://jsfiddle.net/tj_vantoll/Wzrud/.

[Kiruwagaka]

Any updates or workarounds available for this bug yet?