10

I have a little problem with jQuery UI's droppable component, but I'm not quite sure whether I have that problem because of my code or because of a bug in the component.

I have a div with a fixed width and height. The overflow-x for that div is set to hidden, overflow-y is set to auto. Within that div I have some more div's. So many of them that the outer div starts scrolling. Each of the inner divs is a droppable, accepting a draggable which is outside the wrapper div.

If I drag & drop the draggable item somewhere within the wrapper, everything works fine. The problem is that the drop event gets even triggered if I drop the element shortly below the wrapper div.

I'm not really good at explaining the problem; therefore here is some code which reproduces the problem:

http://jsfiddle.net/2p56Y/

Simply drag and drop the "Drag Me!" container below the div with the scrollbar. Unexpectedly you will see the alert "dropped".

Now something interesting: If you scroll down to item "Test28" and now you drag and drop the draggable below the wrapper, the drop event won't be triggered. It looks like the hidden elements are still accessible when you drop something on them.

So, is this a bug or do I need to write my code differently to make it work? (or both? :-) )

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
StefanS
  • 876
  • 1
  • 12
  • 21
  • 2
    It looks like one possible workaround is to add this condition within the function of the drop event: if ( $(this).position().top < $('.box').height() ) see http://jsfiddle.net/5NuLa/2/ – StefanS Feb 05 '11 at 17:03
  • @StefanS: Seems like a reasonable fix to me. – Andrew Whitaker Feb 05 '11 at 17:06
  • It sort of is, but I wonder if one couldn't think up something more elegant. I'll look into the jquery-ui droppable code later. – StefanS Feb 05 '11 at 17:32
  • @StefanS If you inspect DOM elements in Chrome you get a better idea of what happens internally with the browser when overflow attributes are set. Unfortunately it looks like the events will still fire because the elements are still rendered and positioned, but obscured... i.e. it is "visible" to the DOM. You're going to have to write code to check drop position against the parent container bounds. I'll give it a try and see what comes of it. – lsuarez Feb 05 '11 at 18:02
  • @lthibodeaux That's sort of what I thought. It's a pitty there is no filter which truly tells you whether an element is visible. :visible does the job in some situations, but not in this specific one. Maybe it's possible to extent the intersect function of droppable.js to cover this case? https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.droppable.js – StefanS Feb 05 '11 at 18:14
  • Your fix is only good for the bottom, although you really need the top as well (and if you were to have x-scrolling then both sides also), which makes the fix a little uglier. see http://jsfiddle.net/5NuLa/3/ scroll the scrollable div halfway down and then drop the droppable above the dive, same thing happens because you only fixed the bottom. – davin Feb 05 '11 at 18:31
  • To implement a proper viewability check is hard because it's not only in relation to the parent element, but rather *every* parent element. So `.item` needs to be viewable in its parent element, which needs to be viewable in its parent element and so on... More importantly, it isn't a boolean value, like visibility. Because even if a small amount is not viewable, that doesn't mean it shouldn't be droppable (in this scenario). Detailing that properly is not simple – davin Feb 05 '11 at 18:36
  • @davin you're right, my solution only covers the area below the wrapper. I think I was a little blinded by my actual use case in which the wrapper is at the top of the page, so one can't drop above it :-) I agree with you, there is no easy solution; i'll probably go with what I have or with lthibodeaux's solution below. – StefanS Feb 05 '11 at 18:52

3 Answers3

3

Check the droppable element's bounds against the parent container and break the execution of the function if the droppable's bottom is above the parent's top or the droppable's top is beneath the parent's bottom:

$('.item').droppable( {
    activeClass: "ui-state-default",
    hoverClass: "ui-state-hover",
    accept: "#draggable",
    drop: function( event, ui ) {
        var cTop = $(this).closest(".box").position().top + parseInt($(this).closest(".box").css("margin-top"));
        var cBtm = $(this).closest(".box").position().top + parseInt($(this).closest(".box").css("margin-top")) + $(this).closest(".box").height();
        var dTop = $(this).position().top + parseInt($(this).css("margin-top"));
        var dBtm = $(this).position().top + parseInt($(this).css("margin-top")) + $(this).height()

        if (dBtm > cTop && dTop < cBtm) {
            alert("Dropped.");
        }
    }
});

Example: http://jsfiddle.net/lthibodeaux/2p56Y/6/

I realize it's not elegant, but it seems workable. I admit to only cursory testing of this script.

lsuarez
  • 4,952
  • 1
  • 29
  • 51
  • you should make it a little more flexible, if the droppable is one level further down in the DOM this will break. I suggest adding a simple `.data` to a relevant element, that references the appropriate "parent" element, say `$('.box')` in our case. – davin Feb 05 '11 at 18:48
  • Thanks, that seems to work for me and it's a little more general than my check :-) – StefanS Feb 05 '11 at 18:53
  • @davin I'll leave that to the OP. It's a concept more than a universal solution. Could just as easily change parent() to closest(".box"). **EDIT:** Flexible'd. – lsuarez Feb 05 '11 at 19:00
3

You've already accepted an answer, although I thought I should just put it out there:

A more elegant workaround (based on event bubbling and which only really deals with viewability to one level, not recursively) can be made by making $('.box, .item').droppable() and since by default greedy:false the nested div's drop event should trigger, followed by the outer div.

A simple element check like hasClass('box') means that the drop occurred in a valid region, so all you need to do is on the inner drop event cache the element that was dropped into, and then on the outer div's drop event (which happens, as mentioned, only a moment later) do with it whatever.

If you drop outside the outer div, even though the inner div drop event will fire, the outer one wont, so nothing other than a useless cache event happened. The only problem is that it looks like there's a bug with non-greedy nested droppables, the jQuery example http://jqueryui.com/demos/droppable/propagation.html doesn't even work properly for me - it behaves as if it were using event capture and not event bubbling...

The only other (admittedly much more plausible) explanation is that I'm misunderstanding how nested droppables are meant to behave.

davin
  • 44,863
  • 9
  • 78
  • 78
  • Like 50x smarter in my opinion. – lsuarez Feb 05 '11 at 19:10
  • Meh. It was a good idea but it looks like browsers still treat the overflow div like its obscured content are still part of the droppable area. I haven't been able to apply this idea. :[ – lsuarez Feb 05 '11 at 19:18
0

Recently solved this exact same problem so thought I'd share here.

First thing I'll mention is that a similar issue involving nested droppables and event bubbling is solved here. The solution below solves the issue for NON-nested, but overlapping droppables.

THE PROBLEM (IN TECHNICAL TERMS)

If you review OP's jsfiddle using his instructions, you will notice that both of those DOM elements are independent of each other and live on the same DOM "level". However, as OP and a few others have noticed, jQuery UI's Droppable seems to bubble the drop event to DOM elements with overflowing content underlapping the target droppable.

THE SOLUTION

Set a flag when the element is dropped in the target droppable. Check the flag in the drop event of the underlapping DOM element. If this flag contains the value indicating that it has been dropped in the target droppable, return false, do nothing, or revert. Whatever you want to do to ignore the drop event.

For my particular case, I set my flag via a simple attribute value to ui.helper in the target droppable's drop event like so:

$(ui.helper).attr('ignore-drop-event', "true");

In the bubbled drop event on the underlapping droppable, I check that this attribute is set to true:

if ($(ui.helper).attr('ignore-drop-event') === "true") {
    // Ignore this drop event since it occurred as part of event bubbling
}
else {
    // This is a "real" drop event
}

This solution relies on the assumption that

  1. Event bubbling order is consistent. Meaning the target droppable will always receive the event prior to the underlapping droppable element. I don't know if this is always true, but this assessment has been accurate in my testing.

  2. The attribute value is defined prior to the flag check on the bubbled drop event.

Hope this helps someone else out there.

Community
  • 1
  • 1
jdchizzle
  • 623
  • 2
  • 7
  • 12