1932955 - Dragenter/dragleave/dragexit are not properly propagated from a shadow DOM

Status: NEW

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

Description

[David Parks [:handyman]]

A test written for bug 1919554 found that we weren't properly propagating these events
outside a shadow DOM when the drag source and target were in the same frame.
They were instead only sent to the target element itself.

The reason is that we set the relatedTarget for dragenter, dragexit and
dragleave events (Bug 1420590), which the spec doesn't call for. The world
seems to want it, and has since convinced some other browsers to do the same
thing.
So people like it and undoing it would probably break real things.

This fix leaves the behavior but puts it behind a pref that defaults to being on:
dom.event.drag_event_has_related_target. It also adds an exception to event
dispatch for "Step 11.5: Otherwise, if parent and relatedTarget are identical, then
set parent to null" in nsIContent::GetEventTargetParent,
to restore proper bubbling for these events.

Comment 1

[David Parks [:handyman]]

Attachment: Bug 1932955: Give browser_dragdrop_impl.js the HTML files to test drag and drop with r=edgar!

The HTML files were hardcoded but we need the ability to set them to test
elements in a shadow DOM. We also need limited ability to find elements in
shadow DOMs. This patch adds both. It also changes some global variables to
be parameters to setup(). None of these changes substantively affect the
existing tests.

Comment 2

[David Parks [:handyman]]

Attachment: Bug 1932955: Don't use relatedTarget when dispatching dragenter/dragexit/dragleave r=edgar!,masayuki!

These patches include a new DND test that performs DND from/to elements in a
shadow DOM and it found that we weren't properly propagating these events
outside a shadow DOM when the drag source and target were in the same frame.
They were instead only sent to the target element itself.

The reason is that we set the relatedTarget for dragenter, dragexit and
dragleave events (Bug 1420590), which the spec doesn't call for. The world
seems to want it, and has since convinced some other browsers to do the same
thing. So people like it and undoing it would probably break real things.

This patch leaves the behavior but puts it behind a pref that defaults to being on:
dom.event.drag_event_has_related_target. It also adds an exception to event
dispatch for "Step 11.5: Otherwise, if parent and relatedTarget are identical, then
set parent to null", to restore proper bubbling for these events.

Depends on D229982

Comment 3

[David Parks [:handyman]]

Attachment: browser_dragdrop_shadow_inner.html

Writes IDs of targets from various DND events to the console. You can drag the white box to the green box (in Chromium, you can also drag green to white). Both elements are in the same shadow DOM. The logged events are on the document element and are added outside of the shadow DOM. Presumably, none of the logged targets should include elements in the shadow DOM (i.e. dropSource or dropTarget) . Firefox sometimes includes shadow DOM elements "originalTarget" while Chrome sometimes does in "relatedTarget". None of this is difficult to reproduce.

For me, when trying in Chrome, it seems to ignore the dragging the first 5 or 10 times but eventually starts acknowledging them and works fine from then on.

Comment 4

[David Parks [:handyman]]

It seems that the test wasn't propagating the events but somehow nightly is so the issue with the missing tests is something else. Changing this bug to be about the "originalTarget" propagating past a shadow dom boundary.

Comment 5

[David Parks [:handyman]]

(In reply to David Parks [:handyman] from comment #4)

It seems that the test wasn't propagating the events but somehow nightly is so the issue with the missing tests is something else. Changing this bug to be about the "originalTarget" propagating past a shadow dom boundary.

Eh, that was also wrong. The manual test and automated test are working similarly -- the dragenter events I see in the manual test are the ones for the drag source, which properly gets propagated outside the shadow DOM because the prior drag target is unsurprisingly null for the first element in the drag session.

Comment 6

[Phabricator Automation]

Comment on attachment 9439459 [details]
Bug 1932955: Give browser_dragdrop_impl.js the HTML files to test drag and drop with r=edgar!

Revision D229982 was moved to bug 1919554. Setting attachment 9439459 [details] to obsolete.

Comment 7

[Phabricator Automation]

Comment on attachment 9439460 [details]
Bug 1932955: Don't use relatedTarget when dispatching dragenter/dragexit/dragleave r=edgar!,masayuki!

Revision D229983 was moved to bug 1919554. Setting attachment 9439460 [details] to obsolete.