[Webkit-unassigned] [Bug 111023] Threaded HTML parser causes flaky timeout for fast/loader/unload-hyperlink-targeted.html

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=111023





--- Comment #2 from Adam Barth <abarth at webkit.org>  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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.