Read FormSubmission.{method,location} from submitter

[seanpdoyle]

Read FormSubmission.{method,location} from submitter

When a SubmitEvent is fired, it encodes the
element responsible for the submission. This element can be an <input type="submit">, a <button type="submit"> element, or the <form>
element itself (in the case of submissions initiated by
HTMLFormElement.requestSubmit() that omit the submitter argument).

According to the MDN documentation for the event.submitter
property:

An element, indicating the element that sent the submit event to the
form. While this is often an <input> element whose type or a
<button> whose type is submit, it could be some other element which
has initiated a submission process.

If the submission was not triggered by a button of some kind, the
value of submitter is null.

To support submissions from elements other than the <form> that can
declare their own formmethod and
formaction, extend the FormSubmission object to
encode a reference to the submitter, and add an HTMLElement argument
to the FormSubmitObserver and FormSubmissionDelegate methods.

Invokes HTMLFormElement.method instead of
getAttribute("method") to defer gracefully handling missing value
fallbacks to the HTMLFormElement.method implementation.

Include Submitter in FormData

While constructing the FormData during a submission, attempt to read
the submitting <button> element's [name] and
[value] attributes, and encode them as part of the
submission.

While an <input type="submit"> element can have a
[name] and [value] attribute, the value is rendered as the
"button"'s text content.

Form Submitter polyfill

Extend the FormSubmitObserver event listening to track <button type="submit"> and <input type="submit"> clicks in Browsers that
have spotty support.

The implementation is largely ported from both basecamp/turbolinks#4
and rails/rails#33413.

The FormSubmitter type definition is deliberately scoped to the
FormSubmitObserver module, since the Browser-native
SubmitEvent.submitter is only as specific as
HTMLElement, so it's least disruptive to scope
limitations to the polyfilling logic.

[sstephenson]

I really appreciate all the thought that's gone into this change!

[sstephenson]

When TypeScript eventually gets a SubmitEvent definition, I think it'll look more like this:

interface SubmitEvent extends Event {
  submitter: HTMLElement | null
}

since the spec explicitly says submitter might be null. But I agree that HTMLElement | null is a lot less nice to use in method signatures than optional argument syntax.

I think what I'd suggest here is adding the SubmitEvent definition above to globals.d.ts, and then defining the event handler like this:

-  submitBubbled = (event: Event & { submitter?: HTMLElement }) => {
+  submitBubbled = <EventListener>((event: SubmitEvent) => {
     if (event.target instanceof HTMLFormElement) {
       const form = event.target
-      if (this.delegate.shouldInterceptFormSubmission(form, event.submitter)) {
+      const submitter = event.submitter || undefined
+      if (this.delegate.shouldInterceptFormSubmission(form, submitter)) {
         event.preventDefault()
         event.stopImmediatePropagation()
-        this.delegate.formSubmissionIntercepted(form, event.submitter)
+        this.delegate.formSubmissionIntercepted(form, submitter)
       }
     }
-  }
+  })

The explicit cast to EventListener allows it to be passed to addEventListener and removeEventListener without any other declarations.

[javan]

Should probably use the type property here to handle implicit submit <button>s:

<form><button></button></form>

> button.getAttribute("type")
null

> button.type
"submit"

[seanpdoyle]

@javan this is a great call.

From what I remember, TypeScript prevented type property access:

src/polyfills/submit-event.ts|8 col 21 error| 2339[QF available]: Property 'type' does not exist on type 'FormSubmitter'

FormSubmitter is defined within the module:

type FormSubmitter = HTMLElement & { form?: HTMLFormElement }

Would adding type?: string be correct?

[javan]

@sstephenson's probably best equipped to answer that

[jalada]

I got tripped up by this today. In Safari, where this polyfill applies, my form was submitting to its action instead of the formaction defined on the button being clicked because I was missing type='submit' on the button. In Chrome, I didn't need to define that type because the polyfill didn't apply. Once I added type='submit', Safari was happy 🎉 .

This feels like a bug? Happy to open a separate issue if this needs to be tracked separately, or if there's something else I can do to help, please let me know.

[seanpdoyle]

I've opened #49 attempt to resolve this.