DOM submit method does not send name attribute of submit button

RESOLVED WORKSFORME

Status

()

Core
HTML: Form Submission
RESOLVED WORKSFORME
6 years ago
6 years ago

People

(Reporter: John A. Bilicki III, Unassigned)

Tracking

10 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

6 years ago
Created attachment 609175 [details]
submit.php

User Agent: Mozilla/5.0 (Windows NT 5.2; WOW64; rv:10.0.3) Gecko/20100101 Firefox/10.0.3
Build ID: 20120309135702

Steps to reproduce:

1.) Used e.preventDefault() in a DOM submit() event via an event listener to prevent a form from being submitted.

2.) Validated the form using JavaScript.

3.) Submitted the form if valid using the DOM submit() method.


Actual results:

The submit button's name attribute and value attribute's value were not submitted to the server along with the rest of the form.


Expected results:

The submit button's name attribute's value and the value attribute's value should be submitted to the server. This is necessary when there is more than one context in which the form can be submitted. In example a preview or publication of the form's contents may have the server-side scripting call different functions. By providing a submit button for each context it requires only a single click by the user to submit the form in the context in which they prefer.
(Reporter)

Comment 1

6 years ago
Failing Test Results
Array
(
    [post_name] => John
    [post_email] => someone@example.com
    [post_body] => ggggggggggggggggggggggggggggggggggg
)
- - - - - - - - - - - -

Passing Test Results
Array
(
    [post_name] => John
    [post_email] => someone@example.com
    [post_body] => ggggggggggggggggggggggggggggggggggg
    [form_contact1] => Submit Contact Form1
)

Example of PHP server side coding that intercepts the form data...

<?php
else if ($_SERVER['REQUEST_METHOD']=='GET')
{
 //
}
else if ($_SERVER['REQUEST_METHOD']=='POST')
{
 if (isset($_POST['submit_preview'])) {form_preview();}
 else  if (isset($_POST['submit_publish'])) {form_publish();}
}
?>

Comment 2

6 years ago
John, do you have an HMTL testcase that demonstrates this problem?
Component: DOM: Events → HTML: Form Submission
QA Contact: events → form-submission
Submit controls name/value pairs are only sent if it is the submit control the user used to submit the form. But you are using e.preventDefault() in the submit event handler and then you call form.submit(). With form.submit(), no submit control is used. What you should do is canceling the submit event only if the form isn't valid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
OS: Windows Server 2003 → All
Hardware: x86_64 → All
Resolution: --- → WORKSFORME
(Reporter)

Comment 4

6 years ago
Josh, download the PHP version and remove the PHP code though retain the XML declaration and rename to "example.xhtml". Not sure what tools you may have to view POST data without server scripting however.

Mounir, Firefox does not honor the submit button pressed and therefore is less capable than Chrome, Internet Explorer and Safari.

Not fixing this bug means excessive and unnecessary code to be written primarily for Firefox and Opera and should Opera fix this bug exclusively for Firefox.
(In reply to John A. Bilicki III from comment #4)
> Josh, download the PHP version and remove the PHP code though retain the XML
> declaration and rename to "example.xhtml". Not sure what tools you may have
> to view POST data without server scripting however.

It would be appreciated if you could attach an HTML file. If everybody who want to test has to strip down the PHP lines, more than one person is going to waste time...

> Mounir, Firefox does not honor the submit button pressed and therefore is
> less capable than Chrome, Internet Explorer and Safari.

This is a bug in Webkit (this explains why Safari and Chrome have that behavior). Per spec, Gecko (Firefox) and Presto (Opera) have a correct behavior.
Could you be more explicit about versions of IE which behave like that?

> Not fixing this bug means excessive and unnecessary code to be written
> primarily for Firefox and Opera and should Opera fix this bug exclusively
> for Firefox.

Doing:
if (!valid()) { event.preventDefault(); }
instead of:
event.preventDefault(); if (valid()) { form.submit(); }
doesn't seem more code. And that would be compatible with *all* browsers.
(Reporter)

Comment 6

6 years ago
Created attachment 609357 [details]
XHTML copy without PHP code.

Updated

6 years ago
Attachment #609357 - Attachment mime type: application/octet-stream → text/plain
(Reporter)

Comment 7

6 years ago
Josh, the correct mime type is application/xhtml+xml.
Note that the firefox behavior here is per spec. It's a known problem that WebKit behaves this way and I assume they are going to fix it. It just so happens that the behavior is better for you here, but it's worse in many other situations (global variables is generally a bad idea).
(Reporter)

Comment 9

6 years ago
Jonas, point the spec out where it declares it explicitly. WebKit behaves as desired, Firefox does not. "Generally bad" ideas are not absolutely bad ideas.
The .submit method is defined here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#dom-form-submit

It invokes the 'submit' algorithm using the <form> element as the submitter. The 'submit' algorithm is defined here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#concept-form-submit

Step 7 of the 'submit' algorithm is where the set of elements which are included in the dataset is determined. This steps invokes the 'construct the form data set' algorithm defined here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#constructing-the-form-data-set

Step 3.1 of the 'construct the form data set' algorithm skips any input elements whose type is 'submit' unless they are the submitter. Since the .submit method uses the form as the submitter, it thus skips all input elements whose type is 'submit'.
You need to log in before you can comment on or make changes to this bug.