Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#7771 closed bug (notabug)

Droppable incorrectly determining target span

Reported by: draggable Owned by:
Priority: minor Milestone: 1.9.0
Component: ui.droppable Version: 1.8.16
Keywords: Cc:
Blocked by: Blocking:


When adding droppable() to spans, the drop target is incorrectly determined, inconsistently.

In Chrome (Mac), dropping on span elements does not even trigger the event.

In Firefox, dropping on span elements triggers the drop() event, but the span is incorrectly determined. When dragging an item from outside any of the spans, it is correctly determined. But when dragging from inside one of the droppable spans, the inner-most span seems to over-ride the correct one, when Greedy is set (even when dropping outside that span).

This code demonstrates the problem. In Chrome, no drop() events are triggered at all. In Firefox, "Drag Me (Regular)" can be dragged onto Outer or Inner, and the drop() event triggers on the correct target. But when dragging "Drag Me (Inner)", the drop() event triggers on the "inner" span, even if it is dropped on the "outer" span.

<span id="outer" class="drop">

<div>Outer</div> <span id="inner" class="drop">

<div>Inner</div> <div id="inner_drag" class="drag">

Drag Me (Inner)



</span> <div id="regular_drag" class="drag">

Drag Me (Regular)





tolerance: "pointer", greedy: true, drop: function() {




$('.drag').draggable({revert: true});


Change History (6)

comment:1 Changed 9 years ago by draggable

Last edited 9 years ago by draggable (previous) (diff)

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

Resolution: invalid
Status: newclosed

You can't place a div inside a span; that's invalid HTML.

comment:3 Changed 9 years ago by draggable

Problem remains when using divs but setting "display: inline;"

comment:4 Changed 9 years ago by draggable

Problem comes from the fact that jQuery calculates the bounds elements with display:inline based on the elements within them, so they grow as the draggable item is moved around (and thus never exits the inner element of my example).

Partial solution is to use helper:"clone", so that the draggable element itself is never moved (and thus the outer inline element doesn't change size either).

Perhaps a better solution would be to allow the calculation of bounds only at the start of the drag and not update them as the draggable element is dragged (it seems like a variant of this exists: refreshPositions)

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

A better solution is to not put block level elements inside inline elements. It really screws things up and is technically wrong, even if the validators don't catch it.

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

You can use inline-block on the wrappers too, since it's valid for them to contain block level elements.

Note: See TracTickets for help on using tickets.