Event.composedPath() inconsistency between implementors.

[Jack-Works]

For code

const target = new EventTarget()
target.addEventListener('change', (event) => {
    console.log(event.composedPath())
}, { once: true })
const event = new Event('change')
target.dispatchEvent(event)

Chrome and Safari prints [], Firefox prints [target]

https://dom.spec.whatwg.org/#dom-event-composedpath

Per spec, it looks like Firefox is correct.

[annevk]

I think that's right. Would you be willing to add web-platform-tests coverage? Edit: there are some tests for composedPath() in the /shadow-dom/ directory, not nothing covering this. Perhaps even better to add to /dom/events/ given that shadow trees are not involved in your scenario.

cc @rniwa @mfreed7

[Jack-Works]

I wonder which behavior is expected? Since the name composedPath indicates it is for DOM Node, the list missing pure EventTarget might be intended.

[annevk]

Fair, might be good to wait a bit for others to chime in. In my mind this was always the event's path, but we didn't call it that because it had to be partially obscured in the presence of shadow trees. So I would expect Firefox's behavior and if we ever added the ability for userland EventTarget to hook into "get the parent" that would be reflected here as well.

(These days we would probably not add an API that so casually reveals open shadow trees however.)

cc @smaug----

[bathos]

the name composedPath indicates it is for DOM Node

I’m unsure what about the name suggests that. While EventTargets constructed directly from user code never have a non-default “get the parent” algorithm presently, IndexedDB interfaces extending EventTarget do — an IDBRequest’s parent is an IDBTransaction and an IDBTransaction’s parent is an IDBDatabase. The usual bubbling behavior applies.

As far as I can tell, composedPath() for e.g. an IDBRequest success event should reflect this, and in Firefox, it does:

In Chromium presently, I get an empty array.

[Jack-Works]

So should I open the issue in Chrome and Safari?