Bug 6958

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:

Keywords:

HasReduction

Version:

420+

Hardware:

Mac

OS:

OS X 10.4

Bug Depends on:

7080

Bug Blocks:

39021

Attachments:

Description	Flags
Testcase	none
Test case for body onload handler that submits a form that loads itself	none
Test case for body onload handler that submits a URL fragment	none
New Test case proposal.	none

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.