#9758 closed bug (wontfix)

Opened January 20, 2014 11:52PM UTC

Closed January 25, 2014 01:22AM UTC

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

Reported by: benth Owned by: benth
Priority: minor Milestone: none
Component: ui.droppable Version: git (not yet released)
Keywords: Cc:
Blocked by: Blocking:
Description

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

Attachments (0)
Change History (9)

Changed January 21, 2014 03:10PM UTC by tj.vantoll comment:1

status: new → open
summary: Droppable: over/out events not being sent in some cases → Droppable: over/out events not being sent with overlapping elements

Thanks benth.

By chance is this related to #9389?

Changed January 21, 2014 03:17PM UTC by tj.vantoll comment:2

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

Changed January 21, 2014 05:36PM UTC by benth comment:3

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

Changed January 21, 2014 09:20PM UTC by benth comment:4

PR has been updated to include a test case.

Changed January 24, 2014 07:19PM UTC by scottgonzalez comment:5

owner: → benth
status: open → pending

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

Changed January 24, 2014 08:25PM UTC by benth comment:6

status: pending → new

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.

Changed January 24, 2014 10:09PM UTC by scottgonzalez comment:7

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.

Changed January 25, 2014 01:11AM UTC by benth comment:8

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

Changed January 25, 2014 01:22AM UTC by scottgonzalez comment:9

resolution: → wontfix
status: new → closed

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