Sortable: Connected sortables interact poorly with overflow: scroll

#7082 is a duplicate of this ticket.

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

No; sortable will be rewritten for the 2.0 release.

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?

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.

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.

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.

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.

This is my workaround.

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

          return false;
       }

#8039 is a duplicate of this ticket.

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

Any updates or workarounds available for this bug yet?