16430 2012-03-19 07:15:25 +0000 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 2012-12-05 20:51:16 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#form-submission-algorithm P3 normal Unsorted 1 contributor ian ian manish.tripathi.777 mike contributor oldest_to_newest 65726 0 contributor 2012-03-19 07:15:25 +0000 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 70659 1 contributor 2012-07-18 17:15:44 +0000 This bug was cloned to create bug 18095 as part of operation convergence. 74376 2 ian 2012-09-25 00:02:30 +0000 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? 79246 3 manish.tripathi.777 2012-12-02 08:17:26 +0000 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. 79249 4 ian 2012-12-02 18:53:25 +0000 Ah, I see. Thanks. 79252 5 ian 2012-12-03 00:07:57 +0000 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.) 79259 6 manish.tripathi.777 2012-12-03 06:50:37 +0000 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. 79315 7 ian 2012-12-03 18:57:03 +0000 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. 79430 8 manish.tripathi.777 2012-12-04 19:19:19 +0000 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... 79501 9 ian 2012-12-05 20:51:16 +0000 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.