Make form events bubble again

[trueadm]

This PR changes form events, specifically submit and reset so that behave as native bubbling events. Today, with the modern event system, that means making them not use the capture phase.

There are a few issues though. We want to move towards removing the notion of have a special capture phase for certain events. One effort is to make them listen only to their target element, as we do in this PR: #19278. That works for all tests, apart from the recent regression test that @gaearon added, where we expect submit to be event replayed. We can't replay events that are only attached to their target, as that means we'll double-fire if we try to listen to them on the root too.

Moving submit and reset to bubble phase sound sensible then right? They natively bubble anyway according to DOM spec, and this includes all major browsers we support. The issue is that we have a Jest test and a reference PR that shows where this went wrong in the past:

#13462

Can we maybe go back and fix this problem internally? Then it would unblock this particular set of events and make them behave as they should do. It would also mean that we don't need to treat it as a target only event in #19278, and thus the test that @gaearon added should pass.

[codesandbox-ci]

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit 04320fd:

Sandbox	Source
React	Configuration

[sizebot]

No significant bundle size changes to report.

Size changes (stable)

Generated by 🚫 dangerJS against 04320fd

[sizebot]

No significant bundle size changes to report.

Size changes (experimental)

Generated by 🚫 dangerJS against 04320fd

[trueadm]

Alternatively, we could change the Jest test for testing submit for event replaying so that it only tests this logic without event replaying. @sebmarkbage would this be a suitable compromise? I'd love your thoughts.

[bvaughn]

I don't feel like I have enough context to approve or reject this PR. Seems like the answer hinges on this question:

Can we maybe go back and fix this problem internally?

So then my question is: Who should make that decision? (That's the thing I really don't have context on- how much effort would it be to fix Workplace.)

[trueadm]

@bvaughn

So then my question is: Who should make that decision? (That's the thing I really don't have context on- how much effort would it be to fix Workplace.)

I'm looking into this now with @philipp-spiess. If we can't make this change though, the only other thing would be to not do this PR right now, and keep capture and reset events on the target. That would also mean removing them from event replaying, which @sebmarkbage would have to be happy with, until he can implement his ideas around changing replaying to the capture phase.

[trueadm]

I've put up an alternative approach: #19300

[gaearon]

which @sebmarkbage would have to be happy with

😄