NEW Bug 6958
form submit in onload handler causes an infinite loop 
https://bugs.webkit.org/show_bug.cgi?id=6958
Summary form submit in onload handler causes an infinite loop
Joost de Valk (AlthA)
Reported 2006-01-30 23:20:32 PST
Testcase forthcoming but this is the code: <body onload="document.getElementById('form').submit()"> <form id="form"></form> </body> This will cause an infinite loop, hanging safari.
Attachments
Testcase (90 bytes, text/html)
2006-01-30 23:21 PST, Joost de Valk (AlthA) 		no flags
Details
Test case for body onload handler that submits a form that loads itself (597 bytes, text/html)
2011-07-26 17:46 PDT, Kevin H McCullough 		no flags
Details
Test case for body onload handler that submits a URL fragment (498 bytes, text/html)
2011-07-26 17:47 PDT, Kevin H McCullough 		no flags
Details
New Test case proposal. (1.29 KB, text/html)
2011-07-29 12:41 PDT, Kevin H McCullough 		no flags
Details
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Joost de Valk (AlthA)
Comment 1 2006-01-30 23:21:22 PST
Created attachment 6139 [details] Testcase
Dave Hyatt
Comment 2 2006-01-31 14:57:45 PST
I think this may be related to the infinite loop bug with setting window.location.href = "#somelinkonpage" in onload. Try a test case that does that too. I bet they are the same underlying issue. There was some Ajax bug about Really Simple History not working that is related to this too. IMO fixing these bugs is really really important (P1), since it's an infinite loop.
David Kilzer (:ddkilzer)
Comment 3 2006-01-31 21:50:33 PST
Is it really starting an infinite loop, or is the Redirection Timer just started and never stopped during this action? See also Bug 6309.
Darin Adler
Comment 4 2006-02-05 00:48:03 PST
This is really an infinite loop. I think the reason for this is that it submits the form right away, whereas for a location change, we schedule it and it gets done next time around the event loop. I think form submission should be changed to work the same way as other location changes, sharing the "redirection timer" with the rest.
Joost de Valk (AlthA)
Comment 5 2006-02-05 01:21:29 PST
As commented by darin, form submission should time differently. The infinite loop part of this can be found in bug 7080, this bug is now just here to track how we handle form submission.
Alexey Proskuryakov
Comment 6 2007-11-23 01:49:58 PST
Hmm, this seems to have fixed itself between r19809 and r19818 - I don't see any check-ins in this period that look related to this issue (most of them were on branches). I guess we need to land an automated test for this.
Kevin H McCullough
Comment 7 2011-07-26 11:50:20 PDT
I can reproduce on r91704
Kevin H McCullough
Comment 8 2011-07-26 17:46:30 PDT
Created attachment 102083 [details] Test case for body onload handler that submits a form that loads itself
Kevin H McCullough
Comment 9 2011-07-26 17:47:04 PDT
Created attachment 102084 [details] Test case for body onload handler that submits a URL fragment
Kevin H McCullough
Comment 10 2011-07-26 17:58:17 PDT
I uploaded two tests. One for testing if the unload handler submits to a URL fragment and one if it just submits to the current page. For the URL fragment there is no infinite loop, but for the other test WebKit does loop infinitely.
Kevin H McCullough
Comment 11 2011-07-26 18:02:46 PDT
(In reply to comment #4) > This is really an infinite loop. > > I think the reason for this is that it submits the form right away, whereas for a location change, we schedule it and it gets done next time around the event loop. I think form submission should be changed to work the same way as other location changes, sharing the "redirection timer" with the rest. NavigationScheduler::scheduleFormSubmission() calls schedule(adoptPtr(new ScheduledFormSubmission())) Does this mean the submission is using the "redirection timer"? It seems like the infinite loop is because on each new load the body's onload handler is called. However, you are not stuck in this loop, I can click on another link and navigate away from the looping page.
Darin Adler
Comment 12 2011-07-27 12:07:33 PDT
(In reply to comment #11) > However, you are not stuck in this loop, I can click on another link and navigate away from the looping page. That’s right. An infinite reload loop, not a browser or engine hang.
Kevin H McCullough
Comment 13 2011-07-27 12:23:16 PDT
(In reply to comment #12) > (In reply to comment #11) > > However, you are not stuck in this loop, I can click on another link and navigate away from the looping page. > > That’s right. An infinite reload loop, not a browser or engine hang. So what ought to be the fix? The browser is doing what the website is telling it to do.
Darin Adler
Comment 14 2011-07-27 12:23:56 PDT
Do other web browsers do the same thing?
Kevin H McCullough
Comment 15 2011-07-27 12:39:15 PDT
(In reply to comment #14) > Do other web browsers do the same thing? FF (OS X) infinite reloads. It doesn't look like it because the UI isn't updating, but in FireBug it's very obvious. Chrome (OS X) infinite reloads Unfortunately I haven't put Win on this machine yet. But I've been meaning to do that, so maybe now is the time.
Darin Adler
Comment 16 2011-07-27 14:54:41 PDT
The original bug was a true infinite loop. But now it’s just an infinite reload loop. Kevin, you are the one who said you could still reproduce the bug, but you’re just reproducing a reload loop, not a true infinite loop. I think Alexey had it right in comment #6. This is fixed and we need a regression test.
Kevin H McCullough
Comment 17 2011-07-27 17:52:01 PDT
(In reply to comment #16) > The original bug was a true infinite loop. But now it’s just an infinite reload loop. > > Kevin, you are the one who said you could still reproduce the bug, but you’re just reproducing a reload loop, not a true infinite loop. I think Alexey had it right in comment #6. This is fixed and we need a regression test. Agreed. I get the same behavior as I described above on current FF, Chrome, Safari, and IE (on Win 7). I'll make a layout test.
Kevin H McCullough
Comment 18 2011-07-29 12:41:21 PDT
Created attachment 102380 [details] New Test case proposal. This test case tries to test for the "infinite loop" scenario while not reloading forever in the success case. However, as the infinite loop code has not caused the error for so long, I cannot reproduce the old bad-behavior, and so am unable to be certain if this test would catch it.
Note You need to log in before you can comment on or make changes to this bug.