Expectations in pointerevent_after_target_removed_from_slot.html

[mustaqahmed]

The WPT in pointerevents/ is failing in all browsers, and it is not clear if the assertions in the test are spec-compliant.

Let's look at the first sub-test there for ease of discussion. Once we are confident what to expect there, hopefully other sub-tests will be trivial:

---

In the first sub-test "mouse events with remove-slot at pointerdown", we start with the following HTML where #slot is filled with #filler.

<div id="host">
  <template id="template" shadowrootmode="open">
    <style>
      div {
        width: 100px;
        height: 100px;
      }
    </style>
    <div id="parent">
      <slot id="slot">
        <div></div>
      </slot>
    </div>
  </template>

  <div id="filler"></div>
</div>

Then at pointerdown on #filler, #slot is deleted from the shadow-tree. At this point:

• #filler becomes hidden while remaining connected to the light-DOM, and
• the mouse pointer hovers on #parent (the shadow root).

Finally, at pointerup, the event is sent to #parent in all browsers.

Now let's look at two specific differences:

1. Because of the first bullet above, I would expect pointerout and pointerleave events getting dispatched to #filler. Chrome and Safari dispatch them, Firefox does not. What does the spec want in this case?

2. Because of the second bullet above, all browsers send a pointerover event to #parent. Chrome and Safari re-target this event to #host and Firefox does not. In a private email thread, @smaug---- mentioned this is somehow related to [1] above. Could you please elaborate?

[mustaqahmed]

@mfreed7 Wondering what your thoughts are regrading the diffs in shadow-DOM event dispatch.

[mfreed7]

Now let's look at two specific differences:

1. Because of the first bullet above, I would expect pointerout and pointerleave events getting dispatched to #filler. Chrome and Safari dispatch them, Firefox does not. What does the spec want in this case?

I don't know what the spec wants. But this behavior (firing the boundary events) sounds reasonable to me, to avoid developer bugs where only one half of the boundary events are sent. But that's a very mild preference.

2. Because of the second bullet above, all browsers send a pointerover event to #parent. Chrome and Safari re-target this event to #host and Firefox does not. In a private email thread, @smaug---- mentioned this is somehow related to [1] above. Could you please elaborate?

Sending a (retargeted) pointerover to #parent sounds reasonable to me.

[smaug----]

@mustaqahmed relatedTarget is very important part here because it changes event propagation. Can you possible include also what is the .relatedTarget in different browsers in different cases.
The issues Chrome has are, IIRC, related to it leaking shadow element via .relatedTarget to light DOM. We don't want that.

[mustaqahmed]

@mustaqahmed relatedTarget is very important part here because it changes event propagation. Can you possible include also what is the .relatedTarget in different browsers in different cases. The issues Chrome has are, IIRC, related to it leaking shadow element via .relatedTarget to light DOM. We don't want that.

Here is a repro matching the WPT but I added .relatedTarget in the log. The case I focused in the original post here is the default bullet in this repro, and it shows correct related targets in both Chrome and Safari (see the last two lines):

[Removing slot]
pointerout target=filler relTarget=host
pointerleave target=filler relTarget=host
pointerover target=parent relTarget=filler
pointerover target=host relTarget=filler

And Firefox emits this instead:

[Removing slot]
pointerover target=parent relTarget=parent

Few weeks ago you reported this Blink bug with leaked related targets, thanks! The WPT/repro here doesn't show the same leak for whatever reason (perhaps something to do with the depth of the <slot> in the shadow-DOM?), so I would defer that discussion for now.

[nt1m]

(I've transferred this issue to the WPT repo instead of interop, since this particular test is not in interop)