I assume tests will need to be updated too?

I assume tests will need to be updated too?

In particular https://github.com/web-platform-tests/wpt/blob/master/html/semantics/the-button-element/command-and-commandfor/button-event-dispatch.html will need to be refactored.

If we are planning to change .source attribute handling to be similar to .relatedTarget, then this is fine (event would propagate if .target and .source are in different subtrees).

@alice has been exploring solutions for reference target #11148 (comment)

If we are planning to change .source attribute handling to be similar to .relatedTarget, then this is fine (event would propagate if .target and .source are in different subtrees).

Is this something relatedTarget does? I was trying to understand how related target affects event propagation, but I couldn't decipher it from the text.

If we want to make it work similar to relatedTarget that would be a bit more work. See https://dom.spec.whatwg.org/#concept-event-dispatch for how we deal with relatedTarget today.

@annevk Could you explain how relatedTarget affects dispatch in non-spec terms? I've read through the spec a bunch of times, but I'm sadly none the wiser.

At this point I would have to deduce it from first principles again as well I'm afraid.

My reading of this WPT is that relatedTarget doesn't affect the event propagation in anything approximating the way I'm proposing source would.

<outer-component id="outerComponent">
  <!-- outer shadow --><template shadowRootMode="open">
    <button id="relatedTarget">Foo</button>
    <middle-component id="middleComponent">
      <!-- middle shadow --><template shadowRootMode="open" shadowRootReferenceTarget="innerComponent">
        <inner-component id="innerComponent">
          <!-- inner shadow --><template shadowRootMode="open" shadowRootReferenceTarget="target">
            <div id="target"></div>
          </template>
        </inner-component>
      </template>
    </middle-component>
  </template>
</outer-component>

The only time relatedTarget seems to actually impact the event path is step 6.9.7:

Otherwise, if parent is relatedTarget, then set parent to null.

This seems to have been added in whatwg/dom@afac504, with the commit message:

Shadow: do not dispatch an event when target is relatedTarget

For example, when a mouse pointer moves from an element in a shadow tree to
its shadow host, a mouseover event should not be dispatched on the
shadow host. The current spec allows a non-empty event path in this case.

We might (?) need to handle a similar case here, but I don't think that logic is sufficient for how we'd like to propagate events with a source.

I think web-platform-tests/wpt#52276 should cover the test changes?

I can't edit OP so I'll just comment the relevant links.

Chromium Implementation Bug: https://issues.chromium.org/u/1/issues/414826954

WebKit Implementation Bug: https://bugs.webkit.org/show_bug.cgi?id=292368

Firefox Implementation Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1856430 (meta bug for whole feature)

Thanks luke! I put your links in the description

Adding "do not merge yet" as it seems like we need to figure out to what extent we need the same model as event's relatedTarget concept has.

Do we need to work out the specifics to that before we change the composedness?

I think it'd be good to change this sooner rather than later?

I suppose I'll defer to @smaug---- on that, though generally we don't want the specification to be in a known in-between state.