Bug 34315 - Form serialization doesn't include a submit input whose onclick() handler calls form.submit()
Summary: Form serialization doesn't include a submit input whose onclick() handler cal...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Nobody
Depends on: 13012
Blocks: 39021
  Show dependency treegraph
Reported: 2010-01-29 01:27 PST by Josip Rodin
Modified: 2010-05-12 13:24 PDT (History)
2 users (show)

See Also:

test case adapted for running locally (492 bytes, text/html)
2010-01-29 17:18 PST, Alexey Proskuryakov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Josip Rodin 2010-01-29 01:27:07 PST
Hi there.

A user reported a problem with Chrome, which I reproduced with Midori,
so I'm filing this on the WebKit library that my Midori package uses.

The automatic platform detection has limited the version choices to some MacOSX set, which isn't really correct... My Midori and its WebKit library version runs on Linux, while the user's browser identifies as "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.0 (KHTML, like Gecko) Chrome/ Safari/532.0".

When a HTML form does this:

<form method="post" name="statsFRM">
<script type="text/javascript">  
function submitnormal(action) {
        document.statsFRM.action = "?id=something";
<input type="submit" value="Good stuff" name="ok" onclick="submitnormal()">
<input type="submit" value="Bad stuff" name="rej" onclick="submitnormal()">

...the WebKit-based web browsers fail to POST an element named "ok" or "rej"
to the web server.

I could find no obvious explanation for this omission.

http://www.w3.org/TR/html401/interact/forms.html says fairly clearly:

17.13.3 Processing form data
	When the user submits a form (e.g., by activating a submit button),
	the user agent processes it as follows.
	Step one: Identify the successful controls 

17.13.2 Successful controls

	A successful control is "valid" for submission. Every successful
	control has its control name paired with its current value as part
	of the submitted form data set. A successful control must be defined
	within a FORM element and must have a control name.
	If a form contains more than one submit button, only the activated
	submit button is successful.

Hence, the activated submit button *is* supposed to be successful as well
as submitted via POST.

There seems to be no reason for the 'onclick' attribute to void the success
of the activated submit button, at least not per 18.2.3 'Intrinsic events'
which defines it.

Please fix this. TIA.

FWIW the workaround I had to use consists of passing the omitted name
as submitnormal('ok') or submitnormal('rej') in the onclick attribute,
and then constructing a new hidden input element just before submission:
        wanted_action.setAttribute('type', 'hidden');
        wanted_action.setAttribute('name', action);  
        wanted_action.setAttribute('value', action); 

This is also http://bugs.debian.org/566981
Comment 1 Alexey Proskuryakov 2010-01-29 17:17:55 PST
I think that this is technically a duplicate of bug 13012, but the symptom is so different that we should probably track it separately for now.

This JavaScript code is clearly fragile - it makes no sense to call "document.statsFRM.submit();" given that the submission is going to happen anyway (and yes, even the change to action will take effect).

Does this affect any sites in real life? That's usually the primary key to determine priority of fixing issues such as this.
Comment 2 Alexey Proskuryakov 2010-01-29 17:18:21 PST
Created attachment 47748 [details]
test case adapted for running locally
Comment 3 Josip Rodin 2010-01-30 03:53:24 PST
Alexey, you're right, just losing the explicit submit() is a clean workaround, and it seems to do no harm to other browsers. Thanks. Feel free to merge.