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

[smaug----]

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]

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

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]

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]

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]

Also see #2368

[rniwa]

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