Opened 6 years ago

Last modified 6 years ago

#9258 reopened bug

Nested Droppables Call event callbacks in reverse order

Reported by: wesleycho Owned by: wesleycho
Priority: minor Milestone: none
Component: ui.droppable Version: 1.10.2
Keywords: Cc:
Blocked by: Blocking:

Description

If a parent div and child div both droppables and contain drop callbacks, the order the drop callback is bound to the elements determine the order the callbacks fire, instead of the event bubbling up from the child element to the parent as expected for a jQuery event binding.

Change History (10)

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

Owner: set to wesleycho
Status: newpending

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

comment:2 Changed 6 years ago by wesleycho

Status: pendingnew

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.

comment:3 Changed 6 years ago by tj.vantoll

Status: newpending

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?

comment:4 Changed 6 years ago by wesleycho

Status: pendingnew

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.

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

Status: newpending

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?

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

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

comment:7 Changed 6 years ago by trac-o-bot

Resolution: invalid
Status: pendingclosed

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!

comment:8 Changed 6 years ago by wesleycho

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.

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

Resolution: invalid
Status: closedreopened

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

comment:10 Changed 6 years ago by wesleycho

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.

Last edited 6 years ago by wesleycho (previous) (diff)
Note: See TracTickets for help on using tickets.