Threaded HTML parser causes flaky timeout for fast/loader/unload-hyperlink-targeted.html

• Component: WebCore Misc.
• Status: RESOLVED FIXED

[Adam Barth]

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>

[Eric Seidel (no email)]

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]

> 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]

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]

fast/dom/Window/Location/set-location-after-close.html too

[Dirk Pranke]

(marking this as flaky ...)

[Dirk Pranke]

Seems to be fine now. Closing.