111023 2013-02-27 16:05:28 -0800 Threaded HTML parser causes flaky timeout for fast/loader/unload-hyperlink-targeted.html 2013-09-20 11:58:03 -0700 1 1 1 Unclassified WebKit WebCore Misc. 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED P2 Normal --- 106127 1 abarth webkit-unassigned dpranke eric syoichi tonyg oldest_to_newest 843593 0 abarth 2013-02-27 16:05:28 -0800 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> 843599 1 eric 2013-02-27 16:12:36 -0800 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. :) 843608 2 abarth 2013-02-27 16:24:02 -0800 > 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. 843617 3 abarth 2013-02-27 16:57:13 -0800 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. 843851 4 abarth 2013-02-28 01:04:45 -0800 fast/dom/Window/Location/set-location-after-close.html too 844507 5 dpranke 2013-02-28 14:56:31 -0800 (marking this as flaky ...) 931500 6 dpranke 2013-09-20 11:58:03 -0700 Seems to be fine now. Closing.