| Summary: | form submit in onload handler causes an infinite loop | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Joost de Valk (AlthA) <joost> | ||||||||||
| Component: | Forms | Assignee: | Nobody <webkit-unassigned> | ||||||||||
| Status: | NEW --- | ||||||||||||
| Severity: | Major | CC: | ap, BugZilla, darin, ddkilzer, ian | ||||||||||
| Priority: | P2 | Keywords: | HasReduction | ||||||||||
| Version: | 420+ | ||||||||||||
| Hardware: | Mac | ||||||||||||
| OS: | OS X 10.4 | ||||||||||||
| Bug Depends on: | 7080 | ||||||||||||
| Bug Blocks: | 39021 | ||||||||||||
| Attachments: |
|
||||||||||||
Created attachment 6139 [details]
Testcase
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. Is it really starting an infinite loop, or is the Redirection Timer just started and never stopped during this action? See also Bug 6309. 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. 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. 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. Created attachment 102083 [details]
Test case for body onload handler that submits a form that loads itself
Created attachment 102084 [details]
Test case for body onload handler that submits a URL fragment
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. (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. (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. (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. Do other web browsers do the same thing? (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. 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. (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. 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.
|
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.