Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should event.stopPropagation() during capturing prevent the bubbling phase? #916

Open
domenic opened this issue Nov 5, 2020 · 8 comments
Labels
interop Implementations are not interoperable with each other topic: events

Comments

@domenic
Copy link
Member

domenic commented Nov 5, 2020

Originally jsdom/jsdom#3070.

Example code (live version):

const element = document.createElement("div");

element.addEventListener("click", () => {
  console.log("capture listener");
  event.stopPropagation();
}, { capture: true });

element.addEventListener("click", () => {
  console.log("bubble listener");
});

element.dispatchEvent(new MouseEvent("click", { bubbles: true, cancelable: true }));

In Safari, and per the spec (and in jsdom): logs only "capture listener".

In Firefox and Chrome: logs "capture listener" and then "bubble listener"

Which should it be?

@alexreardon also notes that the domintro for stopPropagation, which reads

When dispatched in a tree, invoking this method prevents event from reaching any objects other than the current object.

implies to him it should be the Firefox and Chrome behavior.

@domenic domenic added interop Implementations are not interoperable with each other topic: events labels Nov 5, 2020
@WebReflection
Copy link

FWIW, I think Safari is right.

@annevk
Copy link
Member

annevk commented Nov 6, 2020

This is the result of #686 and #750.

It took me a while to find the relevant bugs, but it seems they are:

It does seem we need to update the domintro here. What do you all think about adding "or event listeners on the current object whose capture is different"?

@alexreardon
Copy link

Thanks for that research @annevk

I think those two bugs listed are regarding the ordering of which event listeners is called, where capture listeners are always called before bubble listeners, even on the target (which is great).

However, the issue being raised here regards calling event.preventDefault() inside of a capture listener on the target. Based on our understanding of the spec, calling event.preventDefault() inside of a capture listener on the target should prevent the bubble listener on the target from being called. That is the behaviour in Safari and jsdom. However, in Chrome and Firefox calling event.preventDefault() inside of a capture listener on the target will still result in the bubble listeners on the target being called.

@alexreardon
Copy link

(there is also much more background information in the jsdom issue: jsdom/jsdom#3070)

@annevk
Copy link
Member

annevk commented Nov 8, 2020

Right, once the Chrome and Firefox bugs I listed are fixed, they will behave the same as Safari and jsdom.

@alexreardon
Copy link

I wasn't sure if the bugs listed addressed the event.preventDefault() behaviour on the target

@domenic
Copy link
Member Author

domenic commented Nov 19, 2020

Seems like there's no normative spec issue here. Should we leave this open to track updating the domintro?

@josepharhar
Copy link
Contributor

josepharhar commented Dec 9, 2020

I am currently implementing https://bugs.chromium.org/p/chromium/issues/detail?id=1052152 and it looks like in the process of doing so I am also implementing the desired behavior of this issue as a side effect. I will add a WPT for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interop Implementations are not interoperable with each other topic: events
Development

No branches or pull requests

5 participants