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

Figure out if submit and reset events need to be handled in special way during dispatch #3599

Open
smaug---- opened this issue Mar 28, 2018 · 6 comments

Comments

@smaug----
Copy link

In Gecko submit and reset events stop bubbling if there is another form element as an ancestor.
The old Gecko bug, https://bugzilla.mozilla.org/show_bug.cgi?id=428135

@annevk
Copy link
Member

annevk commented Mar 29, 2018

https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/forms/HTMLFormElement.cpp?l=185 does not even seem to care about an ancestor form element and rather than skipping handling, it just sets the propagation flag. It seems the easiest way to define this would be to change step 5.15 of https://dom.spec.whatwg.org/#dispatching-events (when we handle the BUBBLING_PHASE).

Basically add a new step at the end there:

If event's currentTarget == HTMLFormElement && event's currentTarget != event's target && (event's type == "submit" || event's type == "reset"), then set event's stop propagation flag.

@smaug----
Copy link
Author

Doesn't blink call stopPropagation on ancestor form element only. There is after all target_node != this check. Looks very similar to Gecko's aVisitor.mEvent->mOriginalTarget != static_cast<nsIContent*>(this)
https://searchfox.org/mozilla-central/rev/7e663b9fa578d425684ce2560e5fa2464f504b34/dom/html/HTMLFormElement.cpp#479

@annevk
Copy link
Member

annevk commented Mar 29, 2018

Ah right, so it would have to happen before invoke.

(Technically we could also do this via "get the parent" I think whereby it prepends an event listener to form that does something roughly equivalent, but it would be observably different in subtle ways so probably not worth it.)

@rniwa
Copy link

rniwa commented Sep 6, 2018

This code appears to have come from https://trac.webkit.org/r19872. We have the same code in WebKit. What's crazy is that event.composedPath() seems to indicate Blink, Gecko, and WebKit all seem to be stopping the propagation instead of shrinking the event path in the first place.

@rniwa
Copy link

rniwa commented Sep 6, 2018

Also see #2368

@rniwa
Copy link

rniwa commented Sep 6, 2018

It looks like this quirk in all browsers only happen during the bubbling phase. Capturing phase goes through all the elements: https://gist.github.com/rniwa/909d60c290ba54b65a472a2cba20dfac

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants