Bug 1366603 - Wait for rAF before waiting the MozAfterPaint in test_deferred_start.html. r=hiro, a=test-only
authorMantaroh Yoshinaga <mantaroh@gmail.com>
Mon, 28 Aug 2017 08:01:31 +0900
changeset 423845 bc8f7e510cc8955cf6041dc4e0577622f3e1b382
parent 423844 02852b5a5b3c6b13029da12b9da5060f88ee2222
child 423846 e9c83e49ec46b763d0529edcb9580837739ba639
push id1517
push userjlorenzo@mozilla.com
push dateThu, 14 Sep 2017 16:50:54 +0000
treeherdermozilla-release@3b41fd564418 [default view] [failures only]
perfherder[talos] [build metrics] [platform microbench] (compared to previous push)
reviewershiro, test-only
bugs1366603, 1341294
milestone56.0
Bug 1366603 - Wait for rAF before waiting the MozAfterPaint in test_deferred_start.html. r=hiro, a=test-only This test called waitForPaints() after creating an animation, but waitForPaints() didn't wait for a MozAfterPaint event actually since DOMWindowUtils.IsMozAfterPaintPending which is checked a MozAfterPaint event has been queued return false[1]. (i.e. This test didn't wait for a MozAfterPaint) This is related to bug 1341294. If gecko can receive a MozAfterPaint corresponded to own paint, waitForPaint() does not need to check for DOMWindowUtils.IsMozAfterPaintPending. This patch is a workaround until bug 1341294 is resolved. [1] http://searchfox.org/mozilla-central/rev/5696c3e525fc8222674eed6a562f5fcbe804c4c7/testing/mochitest/tests/SimpleTest/paint_listener.js#60 MozReview-Commit-ID: 6Rnv8MBP6Se
dom/animation/test/mozilla/file_deferred_start.html
--- a/dom/animation/test/mozilla/file_deferred_start.html
+++ b/dom/animation/test/mozilla/file_deferred_start.html
@@ -99,18 +99,25 @@ promise_test(function(t) {
   // occasionally produce a false negative on one platform, another platform
   // will fail as expected.
   return waitForDocLoad().then(() => waitForIdle())
   .then(() => waitForPaints())
   .then(() => {
     div.animate({ transform: [ 'translate(0px)', 'translate(100px)' ] },
                 { duration: 400 * MS_PER_SEC,
                   delay: -200 * MS_PER_SEC });
-    return waitForPaints();
-  }).then(() => {
+
+    // TODO: Current waitForPaint() will not wait for MozAfterPaint in this
+    // case(Bug 1341294), so this waiting code is workaround for it.
+    // This waitForFrame() uses Promise, but bug 1193394 will be using same
+    // handling of  microtask, so if landed bug 1193394 this test might be
+    // failure since this promise will resolve in same tick of Element.animate.
+    return waitForFrame();
+  }).then(() => waitForPaints())
+  .then(() => {
     const transformStr =
       SpecialPowers.DOMWindowUtils.getOMTAStyle(div, 'transform');
     const translateX = getTranslateXFromTransform(transformStr);
 
     // If the delay has been applied we should be about half-way through
     // the animation. However, if we applied it twice we will be at the
     // end of the animation already so check that we are roughly half way
     // through.
@@ -141,18 +148,22 @@ promise_test(function(t) {
   return waitForDocLoad().then(() => waitForIdle())
   .then(() => waitForPaints())
   .then(() => {
     const animation =
       div.animate({ transform: [ 'translate(0px)', 'translate(100px)' ] },
                   200 * MS_PER_SEC);
     animation.currentTime = 100 * MS_PER_SEC;
     animation.playbackRate = 0.1;
-    return waitForPaints();
-  }).then(() => {
+
+    // As the above test case, we should fix bug 1341294 before bug 1193394
+    // lands.
+    return waitForFrame();
+  }).then(() => waitForPaints())
+  .then(() => {
     const transformStr =
       SpecialPowers.DOMWindowUtils.getOMTAStyle(div, 'transform');
     const translateX = getTranslateXFromTransform(transformStr);
 
     // We pass the playback rate to the compositor independently and we have
     // tests to ensure that it is correctly applied there. However, if, when
     // we resolve the start time of the pending animation, we fail to
     // incorporate the playback rate, we will end up starting from the wrong