Add form.requestSubmit()

[domenic]

Closes #4187.

• At least two implementers are interested (and none opposed):
  • Blink
  • WebKit per Proposal: allow a mode of form.submit() that behaves like clicking a submit button #4187 (comment)
• Tests are written and can be reviewed and commented upon at:
  • html: Add a test for form.requestSubmit() web-platform-tests/wpt#16743
• Implementation bugs are filed: TODO.
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=964062
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1552301
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=197958

(See WHATWG Working Mode: Changes for more details.)

---

/cc @manucorporat and @muan as web developers who were interested in this and helped shape the feature.

Things for reviewers to consider:

• Is the domintro text for web developers helpful enough?
• Are the "is a submit button" and form owner checks the correct ones? We could loosen these in the future, e.g. per @muan's feedback in Need callback for form submit data WICG/webcomponents#187 (comment) we could allow certain form-associated custom elements to be submit buttons.
• TypeError vs. other error types for the checks failing. I don't care very much so I went generic.

---

/acknowledgements.html ( diff )
/forms.html ( diff )

[tkent-google]

"NotFoundError" might be suitable? It's used for TextTrack-TextTrackCue ownership check.

[annevk]

TypeError is nicer if we ever want to abstract this into IDL.

[domenic]

I don't think we could feasibly put this into the IDL type system... I'm reasonably convinced by the symmetry with the existing ownership check. I'll switch.

[tkent-google]

… TODO. @tkent-google maybe could help write these as part of the Blink implementation?

Yes, I'll make Blink implementation and WPT.

[tkent-google]

Here is a test PR: web-platform-tests/wpt#16743

[annevk]

I guess we somehow know that reentrancy is not a problem here? Does it rely on the protections added for formdata?

[domenic]

Hmm. I guess this does open up the possibility of

form.onsubmit = () => { form.requestSubmit(); }
form.requestSubmit();

We could add a flag to protect against that. I guess we should do so, for symmetry with reset(). Good catch.

Ping @tkent-google to check my logic, and also update the tests.

[tkent-google]

We should have the reentrancy check in form submission algorithm, not in requestSubmit()

click() of a submit button already has a reentrancy issue.

form.onsubmit = () => {
  form.querySelector('[type=submit]').click();
}

When a submit button owned by form is clicked, submit event is dispatched, and click() invokes another form submission.

Chrome, Safari, and Firefox already have a reentrancy check for this pattern, and the form submission invoked by click() is aborted.
On the other hand, form.submit() in submit event handler should be allowed for compatibility.

WebKit/Blink implementation is something like:

• <form> has in-submit-event flag, initially false.
• It should be set to true before firing submit event, and reset to false after it.
• Add "If the submitted from() method flag is not set and in-submit-event flag is true, then return." before step 6 of form submission algorithm.

[domenic]

Thank you for catching that deeper problem. Do you think this flag might be mergeable with the "constructing entry list" flag?

Either way, we should fix that missing check in a separate PR, and rebase this PR on top of it. I am heading to sleep now, but maybe you could work on a spec and tests PR for it? Or I can do it tomorrow.

[tkent-google]

Filed #4620, and
made a specification PR; #4621

[domenic]

This is ready for another look, rebased on top of #4621.

[domenic]

Heads-up @whatwg/documentation