739112 - DOM submit method does not send name attribute of submit button

Status: RESOLVED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[John A. Bilicki III]

Attachment: 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.

Comment 1

[John A. Bilicki III]

Failing Test Results
Array
(
    [post_name] => John
    [post_email] => [e-mail]
    [post_body] => ggggggggggggggggggggggggggggggggggg
)
- - - - - - - - - - - -

Passing Test Results
Array
(
    [post_name] => John
    [post_email] => [e-mail]
    [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

[Josh Matthews [:jdm]]

John, do you have an HMTL testcase that demonstrates this problem?

Comment 3

[Mounir Lamouri (:mounir)]

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.

Comment 4

[John A. Bilicki III]

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.

Comment 5

[Mounir Lamouri (:mounir)]

(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.

Comment 6

[John A. Bilicki III]

Attachment: XHTML copy without PHP code.

Comment 7

[John A. Bilicki III]

Josh, the correct mime type is application/xhtml+xml.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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).

Comment 9

[John A. Bilicki III]

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.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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'.