Closed frickt closed 5 years ago
I think it would be better to get rid of the buggy behavior. Do you want to have a go?
@frickt actually, I can't reproduce your case. Do you have a minimal example where the bug occurs?
Hi marcojakok
While doing the minimal example i found the issue in my code. On drag start I render a new component (to draw an overlay) on top of the current target, this new overlay component gets the new target. When hitting esc key, the draggable_dispatch.reset() method gets called after the onDragEnd event (where I destroy the new overlay component) thus the previousTarget in the reset function does not exist any more and the dispatch of the dragLeaveEvent does not work. When I do a drop to an existing drop zone the draggable_dispatch.reset() method gets called before the onDragEnd event (through draggable_dispatch.dispatchDrop > reset()) so the dragLeaveEvent works as expected.
I've a workaround where I don't create a new component and solve it with pure css (better solution anyway). But may be you could consider dispatching the dragLeaveEvent always before or after the OnDragEnd event.
The dragLeave
is fired on Dropzones
while the dragEnd
is fired on Draggables
. So the order of those two should not matter much. I considered changing the order of the events. But I think it's just for stylistic reasons and with the risk of messing things up, I think we should just leave it as long as no one has a valid use case.
I've the issue, that the dnd-over class stays on the last dragged over element when i abort the dragging with esc-key.
Is there a way to disable the abort with esc?