Re: [WICG/webcomponents] Reference Target: How to handle events fired on the reference target by related elements? (Issue #1098)

dandclark left a comment (WICG/webcomponents#1098)

I learned today that a manually constructed and dispatched event can hit this condition without the use of reference target.

```html
<x-component id="outer">
<template shadowRootMode="open">
    <button id="button">Do Foo</button>
    <x-component id="middle">
    <template shadowRootMode="open">
        <x-component id="inner">
        <template shadowRootMode="open">
            <div id="targetDiv">Target div</div>
        </template>
        </x-component>
    </template>
    </x-component>
</template>
</x-component>

<script>
const outer = document.getElementById("outer");
const button = outer.shadowRoot.getElementById("button");
const middle = outer.shadowRoot.getElementById("middle");
const inner = middle.shadowRoot.getElementById("inner");
const targetDiv = inner.shadowRoot.getElementById("targetDiv");

targetDiv.dispatchEvent(new CommandEvent("command", {source: button}));
</script>
```
In browsers today, this event will only be dispatched on `targetDiv`. With the new behavior being proposed, the event will dispatch on both `targetDiv` and on `middle`. It gets there during this step:

> iv. if event has a source, and event's source's root is a shadow-including ancestor of shadow root, return the result of retargeting target against event's triggering element;

This happens even though there is no reference target in the example, so there is no real relationship between the button `source` and `targetDiv` except for `button` being passed as a `source` in the event constructor. Since this scenario doesn't require reference target that means this'd be a potentially breaking change.

Choices are:
1. Plumb through extra context about the event's `source` such that it's not used to determine the event path if it comes from the event constructor.
 1.a. Or gate the new behavior only to non-manually-constructed events.
2. Follow the new behavior in all cases, accepting it'll be a possibly breaking change.

My prefrence is to at least try (2). Probably need to gather some data first on how common this scenario is.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/1098#issuecomment-4208330326
You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/1098/4208330326@github.com>