Nested Droppables Call event callbacks in reverse order

Your description isn't very clear. Can you please provide a reduced test case showing the problem using jsbin or jsFiddle?

Here you go: http://jsfiddle.net/nfC2J/

To demonstrate bug, drag the "test item" onto "second area", and notice the order of output to console log.

Here's a test case that I think shows this a little better: http://jsfiddle.net/tj_vantoll/zF89v/

@wesleycho What's your use case for needing the events to fire in this order?

I have a playlist listing div that I want to be able to drop another div with an image representing a video into the playlist, where dropping it anywhere will fire a modal which will allow the user to create a new playlist (a child div) with the resource dragged and dropped into the playlist listing div as a part of the new playlist. I also want to be able to have the user drag and drop the resource directly into the playlist, which adds that resource to the playlist, but does not fire the modal to create a new playlist.

This is not possible within the current implementation of event handler binding by the droppable widgets since it uses an array with the order of the callbacks bound being the determining factor as to the order. This is compounded by my usage of AngularJS, since the order directives are compiled, and thus the order the droppable bindings occur, are dictated by the order they appear in the DOM. Ideally, I would like to be able to tap into controlling the order of events present in the jQuery-wrapped event object, but given the implementation of the event handling in the droppable widget, I have subbed a pull request with a proposed fix that offers more control over the ordering based on how deep the element the callbacks are bound to is in the DOM. Combined with the greedy option, this should address the issue of nested callbacks.

Combined with the greedy option, this should address the issue of nested callbacks.

If you're using the greedy option, why does this matter?

Also, why don't you just use the event target to figure out what operation to perform?

Oh, well, I guess you can't use the event target for non-greedy.

Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!

As the plugin currently works, event target is not reliable since it seems the plugin uses its own event system in what seems to be a hackish solution instead of jQuery's built-in bubbling up.

Setting greedy to true does not fix the inherent problem with how the events are handled.

The plugin definitely uses jQuery's built-in event system. That has nothing to do with the order in which events are triggered.

It uses it to an extent, but it adds an extra layer of event handling which makes following the event chain unreliable/incorrect (and hence event.stopPropagation() does not work in accomplishing this goal) - I've mentioned earlier, I submitted a pull request which tweaks this mechanism to order the event callbacks by depth in the DOM, with deeper elements getting higher priority, as should be.