[DRAFT] Propagate events into the event's source's tree where appropriate.

[alice]

When an event is triggered by a source in a different tree from the target, propagate events into the source's tree
(where appropriate) so that event listeners can be added in that tree without needing to have access into the
target's tree.

• Add the concept of a "source" for an Event.
• Modify shadow root's "get the parent" algorithm such that events propagate into the event's source's tree where appropriate.

whatwg/html#11349 pulls the event source concept into the HTML spec.

See WICG/webcomponents#1098 for more information and worked examples.

• At least two implementers are interested (and none opposed):
  • …
• Tests are written and can be reviewed and commented upon at:
  • Some tests are added in https://chromium-review.googlesource.com/c/chromium/src/+/6490687 (also a WIP), but more are needed.
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
  • Deno (only for aborting and events): …
  • Node.js (only for aborting and events): …
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

---

Preview | Diff

[keithamus]

This concept of re-despatching on the host might have confusing consequences for developers, who will be able to observe events pointed at a target that would commonly dispatch those events, but weren't the source of this event. For example:

<button id=b>Hover me</button>
<div id=popoverA popover>
  <template shadowrootmode=open>
    <div id=popoverB popover>
    </div>
  </template>
</div>
<script>
let popoverB = popoverA.shadowRoot.querySelector('#popoverB');
b.addEventListener('mouseover', () => {
  popoverB.showPopover({source:b});
});
b.addEventListener('mouseout', () => {
  popoverB.hidePopover({source:b});
});
</script>

AIUI, In this example, when popoverB is shown it will dispatch a beforetoggle (and toggle) event on popoverB, with a source of b. The event will then also dispatch on popoverA, despite the fact that popoverA isn't being shown. Further to that, the event being dispatched on popoverA would be otherwise identical to an event that popoverA might dispatch - for example the target, source, isTrusted, composed fields etc would all be the same.

This feels like it could make it extremely difficult for developers to ascertain when an event has been dispatched because a host element has/is changed/changing state, or whether one of its shadow descendants happened to do change state and the source element is causing it to re-despatch.

I think for this to move forward it would probably need some kind of additional property on Events, like .wasOriginallyDespatchedInTheTargetsShadowButNowIsBeingRedespatchedInThisTreeBecauseYourSourceElementMightWantToKnowAboutIt. Though I'm not sold on the name; maybe it can be workshopped.

[alice]

@jakearchibald Any thoughts?

I would note only that the same is presumably true for composed events?

[jakearchibald]

@keithamus just paging some of this back in…

Am I right that this isn't really a problem with reference targets, since that creates a deliberate link between the shadow root and the host?

[keithamus]

This might be a problem with reference targets if source is set to the element inside the shadow tree. I don't recall if that's the intention for them.

[alice]

AIUI source in this instance would be the <button>, but the problem @keithamus describes would occur because the event would be propagated out of the shadow tree for that reason (as it would also be for a composed event), and the event would appear to be originating from the shadow host rather than the element it actually originates on.

referenceTarget plays into this issue because it allows <button> to be the source for an event fired on an event inside shadow root even without manually firing the event as in Keith's example:

<button id=b popoverTarget=popoverA>Click me</button>
<!-- even though popoverA has the popover attribute, b refers to popoverB -->
<div id=popoverA popover>
  <template shadowrootmode=open shadowRootReferenceTarget=popoverB>
    <div id=popoverB popover> <!-- an event fired here appears to come from popoverA -->
    </div>
  </template>
</div>

[dandclark]

I did run into a variation of the issue that @keithamus raised here when updating some reference target tests to account for the new event propagation behavior. I worked around it by checking event.composedPath()[0], which for an open shadow root shows the original target inside the shadow root; checking that is roughly equivalent to the .wasOriginallyDespatchedInTheTargetsShadowButNowIsBeingRedespatchedInThisTreeBecauseYourSourceElementMightWantToKnowAboutIt suggested by Keith above. For an example see here.

This doesn't work for closed shadows though. But I'm not convinced this will be a problem for real-world use cases; the test cases are pretty contrived. It seems like a adding a boolean exposing this information even for closed shadows would be an easy backwards-compatible addition if it did turn out to be a something developers run into problems with for closed shadows.

[dandclark]

I'd like to get this reviewed together with the main reference target spec in preparation for potentially shipping in Chromium, so I pulled it into #1353, and pulled whatwg/html#11349 into whatwg/html#10995. @alice let me know if you'd prefer to keep driving it separately and I can back it out.