Droppable: Issue with nested, adjacent, greedy droppables

[maimairel]

Hi, See this jsfiddle: ​http://jsfiddle.net/jSsMy/

If you move the blue box at the bottom into the child droppables (green boxes) then the green boxes will turn yellow.

If you move the blue box from bottom to top, then the parent will also become yellow. But if you move the blue box from top to bottom, then the parent stays red.

The correct behavior is that the parent has to stay red regardless of moving the blue box from top to bottom or bottom to top.

I've been analyzing this for two days, and I'm sure that this is a bug. This is caused by calling the parentInstance._out and parentInstance._over in the same $.each loop in $.ui.ddmanager.drag.

If you move the blue box from bottom to top, then the parentInstance._out will be called when the blue box goes into the box with a lower index (above the green box that the blue box left) in the $.ui.ddmanager.droppables. This means that the parent droppable is going into a greedy child.

Then when the loop reaches the index of the droppable that is left by the blue box (the box below the then hovered box) the parentInstance._over will be called because we're moving out of a greedy child.

In short, this bug causes the parent droppable going into and out of its nested greedy droppable in the same $.each loop.

I've made an un-optimized fix for this, but it should give the general idea of how to fix this behavior.

This behavior should not happen as it causes a nested greedy droppable

This jsfiddle contains the patch for $.ui.ddmanager.drag method: ​http://jsfiddle.net/fvjF4/

[maimairel]

Just discovered my fix wasn't perfect for multiple nested droppables that determines dynamically whether to accept a draggable.

Please investigate and fix this bug :(

[maimairel]

Seems like combining the solution here ​http://bugs.jqueryui.com/ticket/9337, with my fix improves the fix for this bug. But it doesn't solve it yet :(

[tj.vantoll]

I can confirm this.

@maimairel Thanks for taking the time to look into this. Just so you know, we are unlikely to dig into this one until we do our interactions rewrite, which is currently set for 1.13. If you are interested in submitting a patch, please do so as a ​pull request.

[benth]

I'll see if I can fix this, because I think it relates to other isout and isover problems I've seen (#9758).

In this case, I believe the root cause may unconditionally setting isout & isover when moving out of a greedy child. Additional checks are needed, not just for if the droppable moved into a different greedy child, but also checking intersection and acceptance (when moving out of a greedy child, the draggable might not actually intersect with the parent resulting in an incorrect over event, and if the draggable is not accepted by the parent then isout and isover will get set when they shouldn't have been).

[benth]

My analysis above applies to a different situation/bug, not this one, sorry. @maimairel's description suffices.

[reagleton]

I encountered the same bug as @maimarel.

I've tried the patch for the drag method and it works perfectly for me.