Bug 6958 - form submit in onload handler causes an infinite loop
: form submit in onload handler causes an infinite loop
Status: NEW
Product: WebKit
Classification: Unclassified
Component: Forms
: 420+
: Macintosh Mac OS X 10.4
: P2 Major
Assigned To: Nobody
: HasReduction
Depends on: 7080
Blocks: 39021
  Show dependency treegraph
 
Reported: 2006-01-30 23:20 PST by Joost de Valk (AlthA)
Modified: 2011-07-29 12:41 PDT (History)
5 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Joost de Valk (AlthA) 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 Joost de Valk (AlthA) 2006-01-30 23:21:22 PST
Created attachment 6139 [details]
Testcase
Comment 2 Dave Hyatt 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 David Kilzer (:ddkilzer) 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 Darin Adler 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 Joost de Valk (AlthA) 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 Alexey Proskuryakov 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 Kevin H McCullough 2011-07-26 11:50:20 PDT
I can reproduce on r91704
Comment 8 Kevin H McCullough 2011-07-26 17:46:30 PDT
Created attachment 102083 [details]
Test case for body onload handler that submits a form that loads itself
Comment 9 Kevin H McCullough 2011-07-26 17:47:04 PDT
Created attachment 102084 [details]
Test case for body onload handler that submits a URL fragment
Comment 10 Kevin H McCullough 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.
Comment 11 Kevin H McCullough 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.
Comment 12 Darin Adler 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.
Comment 13 Kevin H McCullough 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.
Comment 14 Darin Adler 2011-07-27 12:23:56 PDT
Do other web browsers do the same thing?
Comment 15 Kevin H McCullough 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.
Comment 16 Darin Adler 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.
Comment 17 Kevin H McCullough 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.
Comment 18 Kevin H McCullough 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.