Droppable: over/out events not being sent with overlapping elements

[benth]

There are cases when an acceptable draggable can be over a droppable and yet the droppable will not get an over event.

Here is a test case: ​http://jsfiddle.net/Sw5sM/2/

This happens because the droppable in question was previously able to accept the draggable, so the droppable got visible set to true by prepareOffsets. Then the droppable options change such that it can no longer accept the draggable, but visible remains set to true, so drag will set isover and isout on the droppable. Finally, when the droppable is able to accept the draggable again, and the draggable is already over the droppable, isover will already be set to true so the droppable won't get an over event!

I'll submit a one line pull request shortly, with the fix being to reset visible to false in prepareOffsets

[tj.vantoll]

Thanks benth.

By chance is this related to #9389?

[tj.vantoll]

Also here's the PR to tie the ticket and the PR together: ​https://github.com/jquery/jquery-ui/pull/1181.

[benth]

I believe #9389 is separate (I actually have an idea about what causes that; I'll leave a comment on that ticket).

[benth]

PR has been updated to include a test case.

[Scott González]

What's your actual use case where the acceptable droppables are changing mid-drag?

[benth]

Here's my use-case. I have a dashboard with a number of regions. You can move widgets between the 'regions'. The regions have tolerance set to "pointer".

I also have a 'toolbox' area that shows new widgets and you can drag a widget from that area onto a region. But I only want these new widgets to be droppable on a region once they are fully clear of the 'toolbox' area.

I tried multiple ways of accomplishing this behavior (fiddling with acceptance, scope, tolerance), but was never able to get the exact behavior I wanted. I finally wrote an accept function on the regions that made sure that new widgets were clear of the 'toolbox' area. Even this didn't work, and I dug in to find out why, whereupon I discovered what I consider a bug.

If you have a suggested workaround or a better way of accomplishing what I want I would be most appreciative. I hope my explanation was clear enough.

[Scott González]

I discussed this with benth in IRC. A custom tolerance should solve the issue more elegantly and have much better performance. benth will report back after testing the implementation.

[benth]

I successfully achieved the behavior I wanted with a custom tolerance (and was able to turn off refreshPositions as well). Thanks scott.gonzalez.

[Scott González]

We don't plan on supporting dynamically enabled droppables mid-drag. There are better, and more efficient, implementations as noted above.