Bug 117037 – fast/dom/location-new-window-no-crash.html times out flakily on mac-wk2

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Tim Horton]

http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20(Tests)/r150969%20(9349)/results.html

I can reproduce locally as well.

[Tim Horton]

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

[Tim Horton]

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.

[Tim Horton]

(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.

[Tim Horton]

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.

[Tim Horton]

Created attachment 203381 [details]
patch

[Tim Horton]

I filed https://bugs.webkit.org/show_bug.cgi?id=117044 about the more general fix.

[Tim Horton]

http://trac.webkit.org/changeset/150987