Bug 117037 - fast/dom/location-new-window-no-crash.html times out flakily on mac-wk2
Summary: fast/dom/location-new-window-no-crash.html times out flakily on mac-wk2
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-30 11:45 PDT by Tim Horton
Modified: 2013-05-30 14:31 PDT (History)
2 users (show)

See Also:


Attachments
patch (1.83 KB, patch)
2013-05-30 14:12 PDT, Tim Horton
ap: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Comment 1 Tim Horton 2013-05-30 11:53:12 PDT
Huh, I put logging in where we call notifydone (the third one), and it is getting called:

CONSOLE MESSAGE: line 8: starting
CONSOLE MESSAGE: line 49: closing
CONSOLE MESSAGE: line 57: closed
FAIL: Timed out waiting for notifyDone to be called
Comment 2 Tim Horton 2013-05-30 13:14:21 PDT
setTopLoadingFrame 0x7fbefaf3d9b0
setTopLoadingFrame 0x0
setTopLoadingFrame 0x7fbefad09040
TestRunner::notifyDone isTestRunning: 1, waitToDump: 1, topLoadingFrame: 0x7fbefad09040

(and then notifyDone bails because topLoadingFrame isn't 0)

So I think this is failing because we're closing the subwindow before it's finished loading, leaving WKTR thinking that it still has a pending load.
Comment 3 Tim Horton 2013-05-30 13:22:08 PDT
(In reply to comment #2)
> setTopLoadingFrame 0x7fbefaf3d9b0
> setTopLoadingFrame 0x0
> setTopLoadingFrame 0x7fbefad09040
> TestRunner::notifyDone isTestRunning: 1, waitToDump: 1, topLoadingFrame: 0x7fbefad09040
> 
> (and then notifyDone bails because topLoadingFrame isn't 0)
> 
> So I think this is failing because we're closing the subwindow before it's finished loading, leaving WKTR thinking that it still has a pending load.

The good case looks like this:

setTopLoadingFrame 0x7fa8a3e2a8d0
setTopLoadingFrame 0x0
TestRunner::notifyDone isTestRunning: 1, waitToDump: 1, topLoadingFrame: 0x0
InjectedBundlePage::dump
setTopLoadingFrame 0x0

So the subwindow never starts loading before we dump.
Comment 4 Tim Horton 2013-05-30 14:10:41 PDT
I'm going to add a 0-delay timeout to the test because I'm not sure how to fix the WKTR problem, and file another bug about the general issue.
Comment 5 Tim Horton 2013-05-30 14:12:36 PDT
Created attachment 203381 [details]
patch
Comment 6 Tim Horton 2013-05-30 14:13:48 PDT
I filed https://bugs.webkit.org/show_bug.cgi?id=117044 about the more general fix.
Comment 7 Tim Horton 2013-05-30 14:31:34 PDT
http://trac.webkit.org/changeset/150987