Summary: | Threaded HTML parser causes flaky timeout for fast/loader/unload-hyperlink-targeted.html | ||
---|---|---|---|
Product: | WebKit | Reporter: | Adam Barth <abarth> |
Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED FIXED | ||
Severity: | Normal | CC: | dpranke, eric, syoichi, tonyg |
Priority: | P2 | ||
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Bug Depends on: | |||
Bug Blocks: | 106127 |
Description
Adam Barth
2013-02-27 16:05:28 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. :) > 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. 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. fast/dom/Window/Location/set-location-after-close.html too (marking this as flaky ...) Seems to be fine now. Closing. |