RESOLVED FIXED 111023
Threaded HTML parser causes flaky timeout for fast/loader/unload-hyperlink-targeted.html 
https://bugs.webkit.org/show_bug.cgi?id=111023
Summary Threaded HTML parser causes flaky timeout for fast/loader/unload-hyperlink-ta...
Adam Barth
Reported 2013-02-27 16:05:28 PST
Reduction: === fast/loader/unload-hyperlink-targeted.html === <script> if (window.testRunner) { testRunner.dumpAsText(); testRunner.waitUntilDone(); } </script> <iframe src="resources/unload-hyperlink-targeted-subframe.html"> </iframe> === unload-hyperlink-targeted-subframe.html === <script> addEventListener("unload", function() { top.location = "pass-and-notify-done.html"; }); window.location = "about:blank"; </script>
Attachments
Add attachment proposed patch, testcase, etc.
Eric Seidel (no email)
Comment 1 2013-02-27 16:12:36 PST
These tests are awesome. We can stare at this in person tomorrow if you haven't solved it by then. I'm sure this is just a race. Does scheduling a location change from in an unload handler cancel the previously scheduled change? I assume the parser immediately gets detached/stopped? http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/resources/pass-and-notify-done.html The main resource won't be done loading until that's done loading, right? And that <script> executes before it's done loading. I wonder if: test.html: <script> if (window.testRunner) { testRunner.dumpAsText(); testRunner.waitUntilDone(); } document.location = "pass-and-notify-done.html" </script> is supposed to work or not. :)
Adam Barth
Comment 2 2013-02-27 16:24:02 PST
> I'm sure this is just a race. Yes. The question is why the main thread parser always wins the race. > Does scheduling a location change from in an unload handler cancel the previously scheduled change? I don't think so. Once you get to unload, nothing can stop the navigation from happening. It's already committed. > I assume the parser immediately gets detached/stopped? Yes. The parser will notice that there is a location change pending. > http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/resources/pass-and-notify-done.html > > The main resource won't be done loading until that's done loading, right? Correct. Note, however, that the parser for the main frame is probably done already. > And that <script> executes before it's done loading. Yes. > I wonder if: > > test.html: > <script> > if (window.testRunner) { > testRunner.dumpAsText(); > testRunner.waitUntilDone(); > } > document.location = "pass-and-notify-done.html" > </script> > > is supposed to work or not. :) Yes, that works. I think we'd call that a "client-side redirect." There is a bunch of special code to handle client-side redirects.
Adam Barth
Comment 3 2013-02-27 16:57:13 PST
The difference between the passing and failing case appears to be the timing of the EOF processing. If the EOF comes in before the top.location timer fires, then there's no timeout. If the EOF takes longer and comes in after the top.location timer fires, then the test times out. I need to study the test case more carefully to confirm.
Adam Barth
Comment 4 2013-02-28 01:04:45 PST
fast/dom/Window/Location/set-location-after-close.html too
Dirk Pranke
Comment 5 2013-02-28 14:56:31 PST
(marking this as flaky ...)
Dirk Pranke
Comment 6 2013-09-20 11:58:03 PDT
Seems to be fine now. Closing.
Note You need to log in before you can comment on or make changes to this bug.