dragEndAction is not called on successful drop

[gabrielgrant]

It seems that dragEndAction is only called when the drag ends unsuccessfully (ie not on a drop target), and dragCoordinator.currentDragObject is only updated in these cases too. This seems to mean that there's no straightforward way to track whether an object is actually currently being dragged.

Is this intended behavior? Is there some other way to know if a drag is in-progress?

In case it's relevant, I'm running Chromium Version 62.0.3202.94 (Official Build) Built/Running on Ubuntu

[dgavey]

dragEndAction should only fire on a successful drag. If you need to know if a drag is in progress use the dragStart action on the draggable-object component and track it in your own component.

[dgavey]

Sorry mis-read your comment. It should be working as intended. It should fire on a successful drop.

[dgavey]

Appears to be working in this demo -> http://mharris717.github.io/ember-drag-drop/#/simple

[gabrielgrant]

Thanks for the reply!
You seem to be right about the draggable-object's dragEndAction functionality working in that demo...which makes the behavior I'm seeing even more bizzare :P. Any idea what in my drop handler could be causing the dragEndAction to not fire? (as I said, fairly certain this isn't just a bug in my dragEndAction handler itself or anything: I'm not seeing any errors, and dragCoordinator.currentDragObject is not getting reset either

[gabrielgrant]

To confirm: it does seem to be something within my drop handler that is causing the problem: when I change the drop handler to return immediately, dragEndAction is fired and dragCoordinator.currentDragObject gets reset as expected

[gabrielgrant]

I've confirmed that the problem occurs when a drop handler causes a data change that in turn causes the dropped draggable-object component to be destroyed. It seems this happens because the browser drop event fires before the endDrag event. I'm clearly not well-enough versed in the Ember event loop internals: I'd thought that defer flushing the DOM changes would be deferred until the whole stack of events had fired, but that doesn't seem to be the case (or at least usually is not -- although it seems to happen fairly consistently in this (drop -> apply DOM changes -> endDrag) order, I think I may have observed a couple instances when it didn't. It's possible this was because the JS event loop fired off the endDrag event before returning control to glimmer's dom manipulation code, but I don't seem to be able to repro that right now, so it also could have just been me being mistaken.)

In any case, you can play with a MCVE here: https://ember-twiddle.com/155776d5af6dd8b662fea9a914921329

and I've submitted a PR that fixes my (that) immediate problem: #119

(it wasn't really obvious that this was the problem from my usage, because in my case i'm actually just re-arranging the underlying data, not removing anything entirely, so it took some ember-inspector-ing to realize that the updated underlying data structure was causing the component to be removed in one place and re-created in another)

[PrzemoRevolve]

I'm afraid your PR might break sortable-objects sorting between 2 lists. The current implementation removes the dragged element from one list and inserts int into the other on dragover (which is a bit hard to work with...). When it's removed it will trigger willDestroyElement, which calls your logic, and might break something.