66547 2011-08-19 04:59:19 -0700 dragenter & dragleave events do not include relatedTarget in the event object 2026-03-19 15:42:47 -0700 1 1 1 Unclassified WebKit UI Events 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=242627 https://github.com/web-platform-tests/wpt/pull/58567 http://jsfiddle.net/pimvdb/HU6Mk/8/ BrowserCompat, InRadar P2 Normal --- 1 pimvdb bfulgham ahmad.saleem792 alexreardon andreas ap bfulgham broofa caqittepp-549 cdumez charged2886 dglazkov dipish dominicc fguillen.mail graouts guillaume.brunerie jakob.stahl91 karlcow megan_gardner michaelcpuckett mtraceur nate.whittaker piotr.nalepa robertc thorton webkit-bug-importer wenson_hsieh oldest_to_newest 453746 0 104491 pimvdb 2011-08-19 04:59:19 -0700 Created attachment 104491 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 454337 1 pimvdb 2011-08-20 04:26:07 -0700 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. 504694 2 dipish 2011-11-17 02:57:33 -0800 I confirm the behaviour (tested in Chrome 15.0.874.121). 528545 3 andreas 2012-01-02 09:35:25 -0800 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. 630831 4 mtraceur 2012-05-22 15:37:38 -0700 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. 701102 5 fguillen.mail 2012-08-21 14:01:55 -0700 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 701104 6 fguillen.mail 2012-08-21 14:02:28 -0700 Another StackOverflow thread: http://stackoverflow.com/questions/7110353/html5-dragleave-fired-when-hovering-a-child-element 745631 7 caqittepp-549 2012-10-18 15:22:55 -0700 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. 937891 8 broofa 2013-10-09 05:59:52 -0700 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. 1478886 9 piotr.nalepa 2018-11-15 07:18:57 -0800 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/ 1510467 10 michaelcpuckett 2019-02-27 09:54:00 -0800 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. 1732774 11 feross 2021-02-23 20:43:18 -0800 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 1830560 12 guillaume.brunerie 2022-01-13 08:42:50 -0800 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? 1879703 13 alexreardon 2022-07-01 03:47:31 -0700 I can confirm that `event.relatedTarget` appears to always be `null` on `dragleave` events in Safari 15.5 1882318 14 alexreardon 2022-07-11 18:59:55 -0700 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 1882330 15 alexreardon 2022-07-11 21:28:13 -0700 New bug to track that both dragenter and dragleave don't have event.relatedTarget set -> https://bugs.webkit.org/show_bug.cgi?id=242627 1882567 16 gsnedders 2022-07-12 14:21:24 -0700 (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. 1882570 17 gsnedders 2022-07-12 14:21:55 -0700 *** Bug 242627 has been marked as a duplicate of this bug. *** 1882874 18 alexreardon 2022-07-12 18:19:06 -0700 Here is a workaround for this bug. It is a decent amount of code 😢 https://gist.github.com/alexreardon/10c595cbb840608a2828db56df99fa79 1910618 19 ahmad.saleem792 2022-11-06 04:53:47 -0800 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! 2011974 20 webkit-bug-importer 2024-02-08 15:43:11 -0800 <rdar://problem/122588344> 2187182 21 bfulgham 2026-03-04 17:31:06 -0800 Pull request: https://github.com/WebKit/WebKit/pull/59939 2187476 22 bfulgham 2026-03-05 12:53:49 -0800 (In reply to alexreardon from comment #18) > Here is a workaround for this bug. It is a decent amount of code 😢 > > https://gist.github.com/alexreardon/10c595cbb840608a2828db56df99fa79 The current PR produces the same behavior in Safari and Chrome on alexreardon@gmail.com's test case. 2188036 23 ews-feeder 2026-03-06 23:56:19 -0800 Committed 308850@main (e0f194b565c5): <https://commits.webkit.org/308850@main> Reviewed commits have been landed. Closing PR #59939 and removing active labels. 2191141 24 bfulgham 2026-03-17 14:53:12 -0700 Submitted web-platform-tests pull request: https://github.com/web-platform-tests/wpt/pull/58567 2191860 25 ews-feeder 2026-03-19 15:42:47 -0700 Committed 305413.526@safari-7624-branch (d7d2dbf9ce7e): <https://commits.webkit.org/305413.526@safari-7624-branch> Reviewed commits have been landed. Closing PR #4629 and removing active labels. 104491 2011-08-19 04:59:19 -0700 2011-08-19 04:59:19 -0700 Test case dragleave.html text/html 768 pimvdb PCFET0NUWVBFIGh0bWw+DQo8aHRtbD4NCjxoZWFkPg0KICA8dGl0bGU+ZHJhZ2xlYXZlIGlzc3Vl PC90aXRsZT4NCg0KICA8c2NyaXB0IHR5cGU9J3RleHQvamF2YXNjcmlwdCc+DQogICAgd2luZG93 Lm9ubG9hZD1mdW5jdGlvbigpew0KICAgICAgZG9jdW1lbnQuZ2V0RWxlbWVudEJ5SWQoJ2Ryb3An KS5hZGRFdmVudExpc3RlbmVyKCdkcmFnbGVhdmUnLA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZ1bmN0aW9uKGUpIHsNCiAgICAgICAgICBj b25zb2xlLmxvZyhlLnJlbGF0ZWRUYXJnZXQpOw0KICAgICAgfSk7DQoNCiAgICAgIGRvY3VtZW50 LmdldEVsZW1lbnRCeUlkKCdkcmFnJykuYWRkRXZlbnRMaXN0ZW5lcignZHJhZ3N0YXJ0JywNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmdW5j dGlvbihlKSB7DQogICAgICAgICAgZS5hbGxvd2VkRWZmZWN0ID0gImNvcHkiOw0KICAgICAgICAg IGUuZGF0YVRyYW5zZmVyLnNldERhdGEoInRleHQvcGxhaW4iLCAidGVzdCIpOw0KICAgICAgfSk7 DQogICAgfQ0KICA8L3NjcmlwdD4NCg0KPC9oZWFkPg0KPGJvZHk+DQoNCiAgPGRpdiBpZD0iZHJh ZyIgZHJhZ2dhYmxlPSJ0cnVlIj5kcmFnIG1lPC9kaXY+DQoNCiAgPGhyPg0KDQogIDxkaXYgaWQ9 ImRyb3AiPg0KICAgIGRyb3AgaGVyZQ0KICAgIDxwPmNoaWxkPC9wPg0KICAgIHBhcmVudA0KICA8 L2Rpdj4NCg0KPC9ib2R5Pg0KPC9odG1sPg0K