Bug 6958 - form submit in onload handler causes an infinite loop
: form submit in onload handler causes an infinite loop
Status: NEW
: WebKit
Forms
: 420+
: Macintosh Mac OS X 10.4
: P2 Major
Assigned To:
:
: HasReduction
: 7080
: 39021
  Show dependency treegraph
 
Reported: 2006-01-30 23:20 PST by
Modified: 2011-07-29 12:41 PST (History)


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 PST, 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 PST, Kevin H McCullough
no flags Details
New Test case proposal. (1.29 KB, text/html)
2011-07-29 12:41 PST, Kevin H McCullough
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 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.
------- Comment #1 From 2006-01-30 23:21:22 PST -------
Created an attachment (id=6139) [details]
Testcase
------- Comment #2 From 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.
------- Comment #3 From 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.
------- Comment #4 From 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.
------- Comment #5 From 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.
------- Comment #6 From 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.
------- Comment #7 From 2011-07-26 11:50:20 PST -------
I can reproduce on r91704
------- Comment #8 From 2011-07-26 17:46:30 PST -------
Created an attachment (id=102083) [details]
Test case for body onload handler that submits a form that loads itself
------- Comment #9 From 2011-07-26 17:47:04 PST -------
Created an attachment (id=102084) [details]
Test case for body onload handler that submits a URL fragment
------- Comment #10 From 2011-07-26 17:58:17 PST -------
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.
------- Comment #11 From 2011-07-26 18:02:46 PST -------
(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.
------- Comment #12 From 2011-07-27 12:07:33 PST -------
(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.
------- Comment #13 From 2011-07-27 12:23:16 PST -------
(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.
------- Comment #14 From 2011-07-27 12:23:56 PST -------
Do other web browsers do the same thing?
------- Comment #15 From 2011-07-27 12:39:15 PST -------
(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.
------- Comment #16 From 2011-07-27 14:54:41 PST -------
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.
------- Comment #17 From 2011-07-27 17:52:01 PST -------
(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.
------- Comment #18 From 2011-07-29 12:41:21 PST -------
Created an attachment (id=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.