Droppable: drop event can cause droppables to remain active if any droppable is created/destroyed in the event handler

I ran across this when I was working with a Backbone view. Each view creates a Droppable element. The issue was that, in the drop event, the event handler needed to modify the view's model. This caused the view to re-render itself (by destroying and recreating the Droppable) which had a strange side-effect: sometimes one of the Droppables would remain in an active state even though the dragging was over.

I traced the problem down to the drop (not _drop) handler in jQuery UI. The function performs a linear loop ($.each) over the Droppables in a given Draggable's scope (which it gets from $.ui.ddmanager.droppables). Unfortunately, when it would fire the event handler for the Droppable, since the Droppable was being destroyed and recreated, the ordering in $.ui.ddmanager.droppables would get shuffled by one, causing the next Droppable to be skipped in the loop.

Here is a JsFiddle that shows this behavior: http://jsfiddle.net/voithos/uZLrS/2/

I thought that it would be nice for jQuery UI to handle this because there's no easy/clean way for the event handling code to account for this.

I know that this affects versions 1.10.1, 1.9.2, and 1.8.5, but I would assume that all versions behave this way.

I've reproduced this behavior on Chrome 24 and Firefox 19 running on Linux Mint.

I have a simple fix for this (an alteration to drop to prefetch the UUIDs of the Droppables, and search for each UUID instead of just looping through the current $.ui.ddmanager.droppables) which I will put on Github and ask for a pull request shortly.