Bug 112939 - Flaky Test: fast/performance/performance-now-timestamps.html
Summary: Flaky Test: fast/performance/performance-now-timestamps.html
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: WebKit Review Bot
Keywords: InRadar
Depends on:
Blocks: 50856
  Show dependency treegraph
Reported: 2013-03-21 11:26 PDT by WebKit Review Bot
Modified: 2020-03-31 14:34 PDT (History)
7 users (show)

See Also:

Archive of layout-test-results from gce-cq-02 (969.43 KB, application/zip)
2013-03-21 11:26 PDT, WebKit Review Bot
no flags Details
Update Test Expectations (1.59 KB, patch)
2020-02-06 14:03 PST, Jacob Uphoff
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description WebKit Review Bot 2013-03-21 11:26:26 PDT
This is an automatically generated bug from the commit-queue.
fast/performance/performance-now-timestamps.html has been flaky on the commit-queue.

fast/performance/performance-now-timestamps.html was authored by nduca@chromium.org.

The commit-queue just saw fast/performance/performance-now-timestamps.html flake (text diff) while processing attachment 194291 [details] on bug 112623.
Bot: gce-cq-02  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-3.3.8-gcg-201212281604-x86_64-with-GCEL-10.04-gcel_10.04

The bots will update this with information from each new failure.

If you believe this bug to be fixed or invalid, feel free to close.  The bots will re-open if the flake re-occurs.

If you would like to track this test fix with another bug, please close this bug as a duplicate.  The bots will follow the duplicate chain when making future comments.
Comment 1 WebKit Review Bot 2013-03-21 11:26:30 PDT
Created attachment 194300 [details]
Archive of layout-test-results from gce-cq-02
Comment 3 Jacob Uphoff 2020-02-06 14:01:04 PST
Still being seen.




--- /Volumes/Data/slave/catalina-debug-tests-wk1/build/layout-test-results/fast/performance/performance-now-timestamps-expected.txt
+++ /Volumes/Data/slave/catalina-debug-tests-wk1/build/layout-test-results/fast/performance/performance-now-timestamps-actual.txt
@@ -9,7 +9,7 @@
 PASS secondTimestamp is defined.
 PASS secondTimestamp is >= firstTimestamp + (waitTime / 2)
 PASS elapsed is >= 1
-PASS elapsed < 100 is true
+FAIL elapsed < 100 should be true. Was false.
 PASS successfullyParsed is true
Comment 4 Jacob Uphoff 2020-02-06 14:01:21 PST
I can reproduce with just running the test in iterations.
Comment 5 Jacob Uphoff 2020-02-06 14:03:25 PST
Created attachment 389992 [details]
Update Test Expectations
Comment 6 Radar WebKit Bug Importer 2020-02-06 14:05:04 PST
Comment 7 Truitt Savell 2020-02-06 14:10:12 PST
Comment on attachment 389992 [details]
Update Test Expectations

Clearing flags on attachment: 389992

Committed r255978: <https://trac.webkit.org/changeset/255978>
Comment 8 Mark Lam 2020-03-31 14:34:35 PDT
The test is merely measuring time around a busy wait with window.performance.now(), which is monotonic time.  If the system is busy (as in running a gazillion other layout tests concurrently), the test process can be pre-empted with no guarantee that it will resume executing in time to read the end sample time within any duration that the test expects.  In this case, the test is expecting a duration of 100ms.

This test is just a bad test.