Gabriel Grant

@c-emil I think one potential downside of this is that if the task is doing something fairly specific to a particular component (or other part of your app), it could...

+1

Cool, thanks for taking a look

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...

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...

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...

you can do this with CSS by setting the `inactive` class (for example) on drop targets you want to disable and adding the following rule: ``` .draggable-object-target.inactive{ pointer-events: none; }...

AFAICT the CI failure here doesn't seem to actually be related to this PR -- it seems to be a problem starting headless chrome in the test environment: https://travis-ci.org/mharris717/ember-drag-drop/jobs/329727097#L1947

Thanks, though this seems to not be a perfect fix: it appears that (sometimes?) after the `willDestroyElement()` cleanup has happened, the `dragEnd()` event _will_ fire, causing `dragCoordinator.dragEnded()` to be called...

not sure why this is failing (I can't actually see the deploy details in vercel), but it seems unlikely it'd be anything directly related to this change...