Event.composedPath() inconsistency between implementors. about dom HOT 5 OPEN

So should I open the issue in Chrome and Safari?

from dom.

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.

from dom.

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

from dom.

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

from dom.

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----

from dom.