Opened 6 years ago

Closed 6 years ago

#9758 closed bug (wontfix)

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

Change History (9)

comment:1 Changed 6 years ago by tj.vantoll

Status: newopen
Summary: Droppable: over/out events not being sent in some casesDroppable: over/out events not being sent with overlapping elements

Thanks benth.

By chance is this related to #9389?

comment:2 Changed 6 years ago by tj.vantoll

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

comment:3 Changed 6 years ago by benth

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

comment:4 Changed 6 years ago by benth

PR has been updated to include a test case.

comment:5 Changed 6 years ago by Scott González

Owner: set to benth
Status: openpending

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

comment:6 Changed 6 years ago by benth

Status: pendingnew

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.

comment:7 Changed 6 years ago by 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.

comment:8 Changed 6 years ago by benth

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

comment:9 Changed 6 years ago by Scott González

Resolution: wontfix
Status: newclosed

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

Note: See TracTickets for help on using tickets.