Bug 33685 - fast/dom/Window/timer-resume-on-navigation-back.html is flaky
Summary: fast/dom/Window/timer-resume-on-navigation-back.html is flaky
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Alexey Proskuryakov
URL:
Keywords:
Depends on:
Blocks: 33292
  Show dependency treegraph
 
Reported: 2010-01-14 13:33 PST by Eric Seidel (no email)
Modified: 2015-04-14 22:29 PDT (History)
4 users (show)

See Also:


Attachments
proposed fix (1.91 KB, patch)
2015-04-14 20:45 PDT, Alexey Proskuryakov
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2010-01-14 13:33:50 PST
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?
Comment 1 Eric Seidel (no email) 2010-01-14 13:36:01 PST
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?
Comment 2 Alexey Proskuryakov 2015-04-14 20:40:10 PDT
Eric analysis is correct (I wish that I searched Bugzilla before I rediscovered the same).
Comment 3 Alexey Proskuryakov 2015-04-14 20:45:32 PDT
Created attachment 250776 [details]
proposed fix
Comment 4 Brady Eidson 2015-04-14 21:41:58 PDT
Comment on attachment 250776 [details]
proposed fix

To be fair, when eric made his analysis, I don't think pageshow/hide existed yet. :)
Comment 5 Brady Eidson 2015-04-14 21:42:34 PDT
(NM, in 2010 they probably did...?)

Anyways, nice change.
Comment 6 WebKit Commit Bot 2015-04-14 22:29:30 PDT
Comment on attachment 250776 [details]
proposed fix

Clearing flags on attachment: 250776

Committed r182838: <http://trac.webkit.org/changeset/182838>
Comment 7 WebKit Commit Bot 2015-04-14 22:29:33 PDT
All reviewed patches have been landed.  Closing bug.