Bug 43840 – fast/loader/recursive-before-unload-crash.html is flaky

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Steve Block]

This test has been observed to fail on the commit queue bot. See 
https://bugs.webkit.org/show_bug.cgi?id=43443#c5 and #c7.

The test was added in the fix for Bug 38928

[Eric Seidel (no email)]

*** Bug 41871 has been marked as a duplicate of this bug. ***

[Eric Seidel (no email)]

This remains our most flaky test.  We need to either skip it or fix it.  See Bug 41871 for an example of the failure.

[Eric Seidel (no email)]

CQ false rejections in recent memory due to this test:

https://bugs.webkit.org/show_bug.cgi?id=45078#c3
https://bugs.webkit.org/show_bug.cgi?id=41812#c4
https://bugs.webkit.org/show_bug.cgi?id=41684#c5
https://bugs.webkit.org/show_bug.cgi?id=41582#c7
https://bugs.webkit.org/show_bug.cgi?id=39482#c14
https://bugs.webkit.org/show_bug.cgi?id=41317#c4
https://bugs.webkit.org/show_bug.cgi?id=38548#c32

In order to cause a false rejection a test has to fail, then not fail, then fail again!  So 2 out of 3!  A single failure won't cause a false rejection and will instead cause the cq to just spin again.  Flaky tests are the main cause of cq delays actually.

[Eric Seidel (no email)]

Here is the failure diff:

--- /tmp/layout-test-results/fast/loader/recursive-before-unload-crash-expected.txt     2010-07-09 13:38:55.000000000 -0700
+++ /tmp/layout-test-results/fast/loader/recursive-before-unload-crash-actual.txt       2010-07-09 13:38:55.000000000 -0700
@@ -6,8 +6,8 @@
 main frame - didStartProvisionalLoadForFrame
 ALERT: Adding iframe
 frame "<!--framePath //<!--frame0-->-->" - didStartProvisionalLoadForFrame
-main frame - didCancelClientRedirectForFrame
 frame "<!--framePath //<!--frame0-->-->" - didFailProvisionalLoadWithError
+main frame - didCancelClientRedirectForFrame
 main frame - didFailProvisionalLoadWithError
 This test demonstrates a problem with our handling of the beforeunload event.
 If a script manages to try and navigate the frame from beforeunload - when a navigation is already pending - we end up blowing out the stack by recursively consulting the policy delegate then running onbeforeunloa
d repeatedly.

[Eric Seidel (no email)]

BTW, this was added 4 months ago by http://trac.webkit.org/changeset/59384 for https://bugs.webkit.org/show_bug.cgi?id=38928.

http://trac.webkit.org/browser/trunk/LayoutTests/fast/loader/recursive-before-unload-crash.html

It's been flaky since at least 2010-06-07 (see the failure links above) and I believe it's been flaky since it landed.

[Eric Seidel (no email)]

In https://bugs.webkit.org/show_bug.cgi?id=38928#c27 Brady talks about removing the callbacks from the test.  I'll see if I can prep a patch to do so.

[Eric Seidel (no email)]

Created attachment 66395 [details]
Patch

[Eric Seidel (no email)]

Committed r66681: <http://trac.webkit.org/changeset/66681>