Bug 111023 - Threaded HTML parser causes flaky timeout for fast/loader/unload-hyperlink-targeted.html
Summary: Threaded HTML parser causes flaky timeout for fast/loader/unload-hyperlink-ta...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 106127
  Show dependency treegraph
 
Reported: 2013-02-27 16:05 PST by Adam Barth
Modified: 2013-09-20 11:58 PDT (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adam Barth 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>
Comment 1 Eric Seidel (no email) 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. :)
Comment 2 Adam Barth 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.
Comment 3 Adam Barth 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.
Comment 4 Adam Barth 2013-02-28 01:04:45 PST
fast/dom/Window/Location/set-location-after-close.html too
Comment 5 Dirk Pranke 2013-02-28 14:56:31 PST
(marking this as flaky ...)
Comment 6 Dirk Pranke 2013-09-20 11:58:03 PDT
Seems to be fine now. Closing.