WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
UNCONFIRMED
Bug 66547
dragenter & dragleave events do not include relatedTarget in the event object
https://bugs.webkit.org/show_bug.cgi?id=66547
Summary
dragenter & dragleave events do not include relatedTarget in the event object
pimvdb
Reported
2011-08-19 04:59:19 PDT
Created
attachment 104491
[details]
Test case Scenario: - a drag element - a drop target element, which has a child element - drop target element has a 'dragleave' event bound which uses e.relatedTarget Problem: In the event handler for 'dragleave', 'e.relatedTarget' is null. This is unfortunate, because when dragging inside the drop target element from the parent into the child, 'e.relatedTarget' is not the parent element. As a result, it is impossible to determine whether the dragging is still happening inside the parent element or that the mouse dragged outside the parent element. This property is available on Firefox and should be available as said in the specification:
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-mouseevents
Attachments
Test case
(768 bytes, text/html)
2011-08-19 04:59 PDT
,
pimvdb
no flags
Details
View All
Add attachment
proposed patch, testcase, etc.
pimvdb
Comment 1
2011-08-20 04:26:07 PDT
I did a quick research and it looks like that 'relatedTarget' is indeed not passed.
http://www.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/page/EventHandler.cpp&l=1725
The penultimate argument which is passed to MouseEvent::create (which corresponds to the 'relatedTarget' parameter) is '0' and is probably therefore 'null' in JavaScript.
Dipish
Comment 2
2011-11-17 02:57:33 PST
I confirm the behaviour (tested in Chrome 15.0.874.121).
Andreas Blixt
Comment 3
2012-01-02 09:35:25 PST
I can reproduce this on "AppleWebKit/535.8 Chrome/17.0.944.0" and "AppleWebKit/535.7 Chrome/16.0.912.63". Due to the lack of relatedTarget, I have not found a feasible workaround for doing consistent effects based on dragenter/dragleave, beyond keeping extra state outside of the events that keeps track of whether any dragenter events have been triggered on child element.
Mark Holmquist
Comment 4
2012-05-22 15:37:38 PDT
I can confirm this happening with Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.19 (KHTML, like Gecko) Ubuntu/12.04 Chromium/18.0.1025.151 Chrome/18.0.1025.151 Safari/535.19 It would be awesome if someone could implement this, instead of leaving drag events broken, because it really makes things difficult.
Fernando Guillen
Comment 5
2012-08-21 14:01:55 PDT
Same issue here: Having this nested DOM elements: <div id="drop"> <div>drop here</div> </div> I want to capture dragenter and dragleave in the whole #drop element so I can play with its CSS: $("#drop").on( "dragenter", function() { $("#drop").addClass( "dragOver" ); }); $("#drop").on( "dragleave", function() { $("#drop").removeClass( "dragOver" ); }); The problem is that when I'm dragging over this element and my mouse arrives to the nested element the dragleave event is triggered so I lost my CSS behavior. This behavior is completely non-consistent with other events like mouesenter and mouseleave which work properly with nested elements. Another non-consistent behavior is that if I move out of the nested element again the dragenter event is not triggered, and I have to leave completely the outer element and go again into it so the dragenter event is triggered. Check the jsFiddle example:
http://jsfiddle.net/fguillen/473kH/
in this example you can play with the normal mouse events and check their behavior in comparison with the drag events. StackOverflow thread:
http://stackoverflow.com/questions/10867506/dragleave-of-parent-element-fires-when-dragging-over-children-elements
Failing in: Chrome OSX Firefox OSX Safari OSX
Fernando Guillen
Comment 6
2012-08-21 14:02:28 PDT
Another StackOverflow thread:
http://stackoverflow.com/questions/7110353/html5-dragleave-fired-when-hovering-a-child-element
caqittepp-549
Comment 7
2012-10-18 15:22:55 PDT
This is fixed in Firefox with either relatedTarget or dragexit. Either would be welcome since it's now a year later and still not possible to do drag and drop without hacks in the world's most advanced and most used browser.
Robert Kieffer
Comment 8
2013-10-09 05:59:52 PDT
Chrome version of this bug:
https://code.google.com/p/chromium/issues/detail?id=159534
Mozilla bug where this issue was fixed in Firefox:
https://bugzilla.mozilla.org/show_bug.cgi?id=458613
Mozilla's support for the relatedTarget attribute solves this problem, and makes sense given how the mechanics of mouseover/mouseout events are identical to dragenter/dragleave events. It'd be awesome if we could have consistent support for this across browsers. This is definitely a thorn in the side of developers want to implement dropzone effects on all but the simplest DOM structures.
sunpietro
Comment 9
2018-11-15 07:18:57 PST
I have found this issue in Safari 12.0.1 (13606.2.104.1.2). Seems like it's still not fixed. Here's the updated fiddle (I've forked the one mentioned earlier and updated it a bit)
http://jsfiddle.net/7tfm5eL1/
Michael Puckett
Comment 10
2019-02-27 09:54:00 PST
This has been fixed in Chrome
https://bugs.chromium.org/p/chromium/issues/detail?id=159534
I believe this means the bug now exists only Safari.
Feross Aboukhadijeh
Comment 11
2021-02-23 20:43:18 PST
This issue still exists in Safari. It does not exist in Chrome or Firefox. Please fix it. It's causing me to need hacky setTimeout() code to work around this issue in my drag-drop library with 150k downloads per month:
https://github.com/feross/drag-drop
Guillaume
Comment 12
2022-01-13 08:42:50 PST
It has now been more than 10 years since the original bug report, and it is still impossible to reliably determine whether a dragleave event actually left the element. Is there any plan to fix it?
alexreardon
Comment 13
2022-07-01 03:47:31 PDT
I can confirm that `event.relatedTarget` appears to always be `null` on `dragleave` events in Safari 15.5
alexreardon
Comment 14
2022-07-11 18:59:55 PDT
Here is a reproducible test case:
https://codesandbox.io/s/event-relatedtarget-for-dragenter-and-dragleave-safari-bug-gpph01
`event.relatedTarget` is always `null` for `dragenter` and `dragleave` events
alexreardon
Comment 15
2022-07-11 21:28:13 PDT
New bug to track that both dragenter and dragleave don't have event.relatedTarget set ->
https://bugs.webkit.org/show_bug.cgi?id=242627
Sam Sneddon [:gsnedders]
Comment 16
2022-07-12 14:21:24 PDT
(In reply to alexreardon from
comment #15
)
> New bug to track that both dragenter and dragleave don't have > event.relatedTarget set ->
https://bugs.webkit.org/show_bug.cgi?id=242627
Let's just generalise this bug and close the other.
Sam Sneddon [:gsnedders]
Comment 17
2022-07-12 14:21:55 PDT
***
Bug 242627
has been marked as a duplicate of this bug. ***
alexreardon
Comment 18
2022-07-12 18:19:06 PDT
Here is a workaround for this bug. It is a decent amount of code 😢
https://gist.github.com/alexreardon/10c595cbb840608a2828db56df99fa79
Ahmad Saleem
Comment 19
2022-11-06 04:53:47 PST
I tried to merge Blink patch in below PR request but I think it is beyond expertise to do so, it compiles on few platforms but not on all: Link -
https://github.com/WebKit/WebKit/pull/5929
Few build errors are easy to fix but in general, I think I might not be able to do it. Appreciate if someone else look into it. Thanks!
Radar WebKit Bug Importer
Comment 20
2024-02-08 15:43:11 PST
<
rdar://problem/122588344
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug