Bug 34315

Summary: Form serialization doesn't include a submit input whose onclick() handler calls form.submit()
Product: WebKit Reporter: Josip Rodin <joy+webkit>
Component: FormsAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: ap, dglazkov
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on: 13012    
Bug Blocks: 39021    
Attachments:
Description Flags
test case adapted for running locally none

Josip Rodin
Reported 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 1.1.15.2 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/3.0.195.38 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"; document.statsFRM.submit(); } --> </script> <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); document.statsFRM.appendChild(wanted_action); This is also http://bugs.debian.org/566981
Attachments
test case adapted for running locally (492 bytes, text/html)
2010-01-29 17:18 PST, Alexey Proskuryakov
no flags
Alexey Proskuryakov
Comment 1 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.
Alexey Proskuryakov
Comment 2 2010-01-29 17:18:21 PST
Created attachment 47748 [details] test case adapted for running locally
Josip Rodin
Comment 3 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.
Note You need to log in before you can comment on or make changes to this bug.