Bug 1437105 Remove flaky timing tests from ESR branch that sometimes fail with time clamping r?baku draft
authorTom Ritter <tom@mozilla.com>
Tue, 06 Mar 2018 16:29:55 -0600
changeset 763950 8d3598b956efe1dc750f50b727b2fa762b4b4372
parent 761553 b4740075dbee86bd3281aacd8858bfbcaee83db7
push id101611
push userbmo:tom@mozilla.com
push dateTue, 06 Mar 2018 22:30:08 +0000
reviewersbaku
bugs1437105
milestone52.6.1
Bug 1437105 Remove flaky timing tests from ESR branch that sometimes fail with time clamping r?baku Because we hardcode time clamping in ESR (as opposed to having a pref) I don't see a way to guarentee that this test won't fail when we lose the race and clamp downwards. MozReview-Commit-ID: IMwejbOBmDu
dom/performance/tests/test_worker_performance_now.js
--- a/dom/performance/tests/test_worker_performance_now.js
+++ b/dom/performance/tests/test_worker_performance_now.js
@@ -21,56 +21,10 @@ function workerTestGetOSCPU(cb) {
 }
 
 ok(self.performance, "Performance object should exist.");
 ok(typeof self.performance.now == 'function', "Performance object should have a 'now' method.");
 var n = self.performance.now(), d = Date.now();
 ok(n >= 0, "The value of now() should be equal to or greater than 0.");
 ok(self.performance.now() >= n, "The value of now() should monotonically increase.");
 
-// The spec says performance.now() should have micro-second resolution, but allows 1ms if the platform doesn't support it.
-// Our implementation does provide micro-second resolution, except for windows XP combined with some HW properties
-// where we can't use QueryPerformanceCounters (see comments at mozilla-central/xpcom/ds/TimeStamp_windows.cpp).
-// This XP-low-res case results in about 15ms resolutions, and can be identified when perf.now() returns only integers.
-//
-// Since setTimeout might return too early/late, our goal is that perf.now() changed within 2ms
-// (or 25ms for XP-low-res), rather than specific number of setTimeout(N) invocations.
-// See bug 749894 (intermittent failures of this test)
-var platformPossiblyLowRes;
-workerTestGetOSCPU(function(oscpu) {
-    platformPossiblyLowRes = oscpu.indexOf("Windows NT 5.1") == 0; // XP only
-    setTimeout(checkAfterTimeout, 1);
-});
-var allInts = (n % 1) == 0; // Indicator of limited HW resolution.
-var checks = 0;
-
-function checkAfterTimeout() {
-  checks++;
-  var d2 = Date.now();
-  var n2 = self.performance.now();
-
-  allInts = allInts && (n2 % 1) == 0;
-  var lowResCounter = platformPossiblyLowRes && allInts;
+workerTestDone();
 
-  if ( n2 == n && checks < 50 && // 50 is just a failsafe. Our real goals are 2ms or 25ms.
-       ( (d2 - d) < 2 // The spec allows 1ms resolution. We allow up to measured 2ms to ellapse.
-         ||
-         lowResCounter &&
-         (d2 - d) < 25
-       )
-     ) {
-    setTimeout(checkAfterTimeout, 1);
-    return;
-  }
-
-  // Loose spec: 1ms resolution, or 15ms resolution for the XP-low-res case.
-  // We shouldn't test that dt is actually within 2/25ms since the iterations break if it isn't, and timeout could be late.
-  ok(n2 > n, "Loose - the value of now() should increase within 2ms (or 25ms if low-res counter) (delta now(): " + (n2 - n) + " ms).");
-
-  // Strict spec: if it's not the XP-low-res case, while the spec allows 1ms resolution, it prefers microseconds, which we provide.
-  // Since the fastest setTimeout return which I observed was ~500 microseconds, a microseconds counter should change in 1 iteretion.
-  ok(n2 > n && (lowResCounter || checks == 1),
-     "Strict - [if high-res counter] the value of now() should increase after one setTimeout (hi-res: " + (!lowResCounter) +
-                                                                                              ", iters: " + checks +
-                                                                                              ", dt: " + (d2 - d) +
-                                                                                              ", now(): " + n2 + ").");
-  workerTestDone();
-};