-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Comments
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:
|
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) |
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.) |
This code appears to have come from https://trac.webkit.org/r19872. We have the same code in WebKit. What's crazy is that |
Also see #2368 |
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 |
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
The text was updated successfully, but these errors were encountered: