Bug 1366603 - Wait for rAF before waiting the MozAfterPaint in test_deferred_start.html. r?hiro draft
authorMantaroh Yoshinaga <mantaroh@gmail.com>
Mon, 28 Aug 2017 08:01:31 +0900
changeset 653743 332450b63031552c96cc206660021e8790f09947
parent 653735 4caca1d0ba0e35cbe57a88493ebf162aa2cb3144
child 728404 275c3c3bb138fd3a61391ae8ea1d465faa530af0
push id76396
push userbmo:mantaroh@gmail.com
push dateSun, 27 Aug 2017 23:01:39 +0000
reviewershiro
bugs1366603, 1341294
milestone57.0a1
Bug 1366603 - Wait for rAF before waiting the MozAfterPaint in test_deferred_start.html. r?hiro 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