Bug 33685 – fast/dom/Window/timer-resume-on-navigation-back.html is flaky

• Component: Tools / Tests
• Status: RESOLVED FIXED

[Eric Seidel (no email)]

fast/dom/Window/timer-resume-on-navigation-back.html failed on Snow Leopard Intel Leaks Bot (Debug)

http://build.webkit.org/results/SnowLeopard%20Intel%20Leaks/r53286%20(3434)/fast/dom/Window/timer-resume-on-navigation-back-diffs.txt

--- layout-test-results/fast/dom/Window/timer-resume-on-navigation-back-expected.txt	2010-01-14 12:52:22.000000000 -0800
+++ layout-test-results/fast/dom/Window/timer-resume-on-navigation-back-actual.txt	2010-01-14 12:52:22.000000000 -0800
@@ -1,3 +1 @@
-This test verifies that when page is loaded from the page cache on navigation back, the suspended timers are resumed for a duration left when they were suspended. This is a test for https://bugs.webkit.org/show_bug.cgi?id=28683.
-The test navigates to a page, starts a timer and then navigates to another page and back. It then measures time when the timer is actually fired and makes sure that it is at least the time set at the beginning. If successful, it outputs 'PASS' below.
-PASS
+

Looks like your classic flakey test. :)  Uses setTimeout.

don't we already have a back-forward controller?

Isn't there some other event we can use to detect if we've gone back-forward yet?

If we haven't, can't we re-schedule another timer and not dump yet?

[Eric Seidel (no email)]

My comments above seem unclear.  What I meant to propose:

1.  We continue scheduling a timeout of 100ms.
2.  We sign up for some event to detect that we've actively gone backwards.
3.  Until we get that event, if our timeout fires, we just keep rescheduling it.
4.  Once we've gotten that event and our timeout has fired, then we dump.

Maybe someone has a better proposal for how to de-flake this test?

[Alexey Proskuryakov]

Eric analysis is correct (I wish that I searched Bugzilla before I rediscovered the same).

[Alexey Proskuryakov]

Created attachment 250776 [details]
proposed fix

[Brady Eidson]

Comment on attachment 250776 [details]
proposed fix

To be fair, when eric made his analysis, I don't think pageshow/hide existed yet. :)

[Brady Eidson]

(NM, in 2010 they probably did...?)

Anyways, nice change.

[WebKit Commit Bot]

Comment on attachment 250776 [details]
proposed fix

Clearing flags on attachment: 250776

Committed r182838: <http://trac.webkit.org/changeset/182838>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.