jQuery Forum

I have a somewhat complex drag and drop scenario, that's revealing a bug in the jQuery UI Sortable code. This happens in 1.8.9, but I have reason to believe it may have existed in earlier builds as well.

Say you have two sortable targets, one above the other.

---------
Area 1
---------
Area 2
---------

As you drag your element around, usually the placeholder appears in the correct area.  The exception is when you drag the element to the final position in either list.   In that cass, there is a scenario where the item will appear in the wrong list, seemingly without fail. That is, if your element is hovering over area 1, the placeholder is in area 2, and vice versa. 

If the areas have a scroll bar, and they are scrolled so that the contents of one 'overlap' the other (ie, if you took the scrollbars away, the content would overlap), then the placeholder ends up in the wrong Sortable.

One thing to note about this is that it seems to work both up and down the page.  If you scroll Area 2 to the bottom and drag an item over Area 1, it'll appear in Area 2.  In fact that scenario is easier to demonstrate, because you can actually see the elements in Area 2 move to accommodate their new friend.

The oddest thing about this is how consistent the behavior is.  I would expect something more arbitrary, like if two nodes overlap, the first one wins, or the last.  Instead it looks like Christmas; whichever is the most 'needy' list gets it, instead of the one most likely to already have it.

I think I could work up a repro case if that wasn't sufficiently clear, but I don't have a canned one to send at present.

In trying to solve a severe performance problem with sortables, I stumbled upon a peculiar calling convention that appears to greatly improve the setup time for complex groupings of sortable lists.   I'm hoping someone can give me some insight into why that is, possibly make some suggestions how to leverage it further, and of course maybe incorporate changes into jQuery UI so that everyone else doesn't have to trick it into performing well. 

I have a page I need to build that has dozens of sortable targets on it.  I can hear you all over there typing away already, to tell me that I shouldn't use that many sortables on a page.  I've never understood what the rationale behind that stance is, aside from, "Well, it's hard for us to get that many wired up on the same page."

It was taking around 6 seconds just for one function call:

$('.sortables').sortable({... connectWith: '.sortables', ...};

Now, this is with 80 div.sortables, on IE 8, on a slow machine, but that's still a long time for one function to complete, and you might guess that's not the only thing the page has to get done.

In attempting to disect the problem, isolate whether my code was exacerbating things or not, or if certain features were causing the problem, I stumbled onto something curious.

$('.sortables').sortable({...};
$('.sortables').sortable({connectWith: '.sortables'};

Splitting 'connectWith' into a separate invocations cut the overall processing time in half. 

For some reason, mixing connectWith into the rest of the heavy lifting done in sortable() severely exacerbates the performance characteristics of the functionality.  I haven't been able to figure out what exactly is causing this, but I'm hoping that data point helps someone on the JQuery UI team figure out how to make sortable() faster for everybody.

The performance difference isn't as profound on other browsers, but it's still noticeably quicker.  Any ideas what causes this?  Are there other phenomena I can exploit in a similar fashion?

Thanks,
Jason