This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16430 - Please review the following: "4. If form is already being submitted...". Probably it would be better to introduce a "form's being-submitted" flag and set it to "true" between steps 6 and 7, then change item 4 to "If the form's being-submitted flag is set
Summary: Please review the following: "4. If form is already being submitted...". Prob...
Status: RESOLVED FIXED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-19 07:15 UTC by contributor
Modified: 2012-12-05 20:51 UTC (History)
3 users (show)

See Also:

Attachments

Description contributor 2012-03-19 07:15:25 UTC 
Specification: http://www.whatwg.org/specs/web-apps/current-work/
Multipage: http://www.whatwg.org/C#form-submission-algorithm
Complete: http://www.whatwg.org/c#form-submission-algorithm

Comment:
Please review the following: "4. If form is already being submitted...".
Probably it would be better to introduce a "form's being-submitted" flag and
set it to "true" between steps 6 and 7, then change item 4 to "If the form's
being-submitted flag is set ... ".  Rationale: if we attempt to implement item
4 as described now, any event handler that calls "form.submit()" in response
to "submit" event will not make it to the actual submission (which is after
step 7), but instead will stop at item 4 (because the form would have already
been being submitted whenever such event handler calls "form.submit()").

Posted from: 82.192.88.2 by manish.tripathi.777@gmail.com
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20100101 Firefox/10.0.2
Comment 1 contributor 2012-07-18 17:15:44 UTC 
This bug was cloned to create bug 18095 as part of operation convergence.
Comment 2 Ian 'Hixie' Hickson 2012-09-25 00:02:30 UTC 
manish: I'm confused. The behaviour described here (form.submit() having no effect) is exactly what the spec is trying to do. Can you elaborate on what the problem is? Maybe with an example?
Comment 3 manish.tripathi.777 2012-12-02 08:17:26 UTC 
Sure. Consider the following scenario.

We have a form with a single submit button and onsubmit JS event handler. The handler does some custom pre-submit processing, then calls form's submit() method, then does post-submit processing, then returns false (to prevent double submission):

<html>
<body>
 <form method="GET" action="/submit" onsubmit="alert('pre-submit'); this.submit(); alert('post-submit'); return false;">
  <input type='submit' value='submit'/>
 </form>
</body>
</html>


In the above scenario, the expected behavior (which is implemented by ie, chrome and mozilla), is:
1. The user clicks submit button, the algorithm fires submit event 
2. The onsubmit event handler calls form's submit() method (according to the script above)
3. *The actual submission takes place* (from the submit() method, not from input button's activation behavior)


However, the algorithm described in http://www.whatwg.org/c#form-submission-algorithm shows different behavior, namely:
1. The user clicks submit button, the algorithm fires submit event 
2. The onsubmit event handler calls form's submit() method
3. The step 4 of the algorithm *aborts submission* because it thinks that the form is already being submitted (which is somewhat true), but does *not* know that the submit event will be cancelled (because the script will return false).
As the result, the actual submission will never take place, which is not what the browsers do.

Therefore, the suggestion is to *allow* form submission algorithm to proceed even if form's submit() method is called from the onsubmit event handler, while at the same time disallowing re-entrant form submission by introducing a "form's being-submitted" flag and setting it to "true" between steps 6 and 7.
Comment 4 Ian 'Hixie' Hickson 2012-12-02 18:53:25 UTC 
Ah, I see. Thanks.
Comment 5 Ian 'Hixie' Hickson 2012-12-03 00:07:57 UTC 
Do you have a testcase demonstrating this? I tried testing it but I found that Gecko and WebKit do what the spec says:

   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1974

(Opera seems to do what you propose. I couldn't test IE.)
Comment 6 manish.tripathi.777 2012-12-03 06:50:37 UTC 
I modified your test case a little : http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1975

You can see how the main page of your website loads in the "rendered view" iframe after you click submit button, and 'onsubmit end' message shows in the log. 

Tested in the following browsers: 
* Google Chrome	23.0.1271.64 (Official Build 165188) m
* Firefox 16.0.2
* IE 9.0.8112.16421

I saw that your test case exhibits different behavior, which I believe is due to the fact that the form had no 'method' attribute and 'action' attribute was a JS URL.
Comment 7 Ian 'Hixie' Hickson 2012-12-03 18:57:03 UTC 
Well that's _fascinating_.

Here's a more thorough version of your test:
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1979

The only way I can explain WebKit's behaviour is that if you call submit() during the handler, it uncancels the event and does the initial submission when you're done, as if you had neither canceled the event nor called submit().

Gecko and Opera seem to have the behaviour you describe; they do submit the form when you call the method, though because it's navigation it's asynchronous so if the event isn't canceled, it never actually happens unless it's javascript:, which happens synchronously.

Not sure why I said Gecko works like WebKit instead of Opera is comment 5. That seems to be wrong.
Comment 8 manish.tripathi.777 2012-12-04 19:19:19 UTC 
Haha. Glad I could puzzle the Guru :-)

I see what you mean and indeed, Webkit's behavior is somewhat different from Gecko, Opera and IE.

However, my point was - all 4 mentioned engines do submit the form when submit() is called from the event handler (though they do it differently, can't argue with that), and many scripts out there rely on this behavior. So maybe we need a little fix for the form submission algorithm...
Comment 9 Ian 'Hixie' Hickson 2012-12-05 20:51:16 UTC 
Yup, definitely need a fix.

Looks like what happened here is that I originally added this, then later realised that what actually happens is the next two steps don't fire when you call submit() anyway, and that that's how the browsers are stopping infinite loops here, but I forgot to remove this step.