I had been thinking how we can test that some kind of optimizations for animations work well, e.g. bug 1166500 or bug 1219236. Last week I noticed that styling markers obtained by nsIDocshell.popProfileTimelineMarkers can be used for those tests. Attaching file is a WIP patch. There are four tests which pass. 1. compositor animations involves no styling on main thread. 2. changing animation duration involves no styling. 3. animation.finish() involves a styling process. 4. transform which causes overflow involves styling on each 200ms. There are seven tests which do not pass yet. 1. mouse movement involves no styling after CSS transition finished. (bug 1219236) 2. mouse movement involves no styling after CSS animation finished. (bug 1219236) 3. compositor animations out of view involves no styling (bug 1166500) 4. main-thread animations out of view involves no styling (bug 1166500) 5. compositor animations in visibility hidden element involves no styling (not filed yet, ex-bug 1166500) 6. main-thread animations in visibility hidden element involves no styling (not filed yet, ex-bug 1166500) 7. changing currentTime involves one styling (not filed yet) No.7 is a brand new issue that I (we?) have never noticed. I believe changing current time should involve only one re-styling process but someone calls another re-styling process there. This issue is not so important but it's worth investigating where the another re-styling comes from. More interestingly no.7 failed intermittently on a try. I may disable the no.7 test. https://treeherder.mozilla.org/#/jobs?repo=try&revision=8b82e7ba32b4&selectedJob=14895673

(In reply to Hiroyuki Ikezoe (:hiro) from comment #0) > 7. changing currentTime involves one styling (not filed yet) > > No.7 is a brand new issue that I (we?) have never noticed. I believe > changing current time should involve only one re-styling process but > someone calls another re-styling process there. This issue is not so > important > but it's worth investigating where the another re-styling comes from. > More interestingly no.7 failed intermittently on a try. I may disable the > no.7 test. Filed as bug 1235478.

I decided to use waitForAnimationFrames in testcommon.js (i.e. requestAnimationFrame) instead of setTimeout in order to eliminate the possibility of intermittent failures.

Review commit: https://reviewboard.mozilla.org/r/29641/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/29641/

Changes from attachment 8702164 [details] [diff] [review]: * waits for all paints before running tests. Otherwise the first test will fail intermittently because of styling process of this html document itself. * adds two test case for animations in elements which are scrolled out. * uses 'is' instead of 'todo_is' for test case of bug 1235478 because patches for that bug will land soon. * removed a test case that transform animations cause overflow are throttled every 200ms because this test case will fail if test machine is under heavy load. e.g., a frame takes over 200ms. Observed on try: https://treeherder.mozilla.org/logviewer.html#?job_id=15067303&repo=try * uses yield instead of then Review commit: https://reviewboard.mozilla.org/r/29643/diff/#index_header See other reviews: https://reviewboard.mozilla.org/r/29643/

Comment on attachment 8704357 [details] MozReview Request: Bug 1235286 - Part 1: Add an argument to waitForAnimationFrames to run a task in each requestAnimationFrame callback. r=birtles https://reviewboard.mozilla.org/r/29641/#review26467 ::: dom/animation/test/testcommon.js:58 (Diff revision 1) > + * Nit: Period at the end of the sentence. Nit: I think it would be easier to scan if we could drop the blank line and group the @param lines together. ::: dom/animation/test/testcommon.js:61 (Diff revision 1) > -function waitForAnimationFrames(frameCount) { > +function waitForAnimationFrames(frameCount, intermediateTask) { What about calling it "onFrame"? Or something like that? "Intermediate task" is a bit unclear to me. Also, the comment for this should say "An optional function..." r=birtles with comments addressed.

Comment on attachment 8704358 [details] MozReview Request: Bug 1235286 - Part 2: Tests for animation optimizations. r?birtles https://reviewboard.mozilla.org/r/29643/#review26473 ::: dom/animation/test/chrome.ini:9 (Diff revision 1) > skip-if = buildapp == 'b2g' This doesn't seem right. I think you want the skip-if to apply to test_running_on_compositor.html, right? (Maybe that test passes on b2g now? If it doesn't, we should probably at least add a bug #.) ::: dom/animation/test/chrome/test_optimizations.html:4 (Diff revision 1) > +<title>Tests that various optimizations for animations</title> This is a bit vague. What exactly are we testing? Are we testing that we don't do unnecessary restyles? Or something else? We should name this file and test accordingly. ::: dom/animation/test/chrome/test_optimizations.html:36 (Diff revision 1) > +function observeStyling(frameCount, intermediateTask) { As with part 1, I think something like "onFrame" would be more clear here. ::: dom/animation/test/chrome/test_optimizations.html:61 (Diff revision 1) > + add_task(function* no_styling_for_compositor_animations() { I think we need to check that compositor animations are enabled since we might turn them off on some platforms. Perhaps we could simply check animation.isRunningOnCompositor and if that's false, just return early. ::: dom/animation/test/chrome/test_optimizations.html:61 (Diff revision 1) > + add_task(function* no_styling_for_compositor_animations() { I think we should add a test that does the same thing for transform since it has slightly different conditions and we want to detect regressions if we change those conditions. ::: dom/animation/test/chrome/test_optimizations.html:61 (Diff revision 1) > + add_task(function* no_styling_for_compositor_animations() { Rather than "no_styling", "no_restyling"? ::: dom/animation/test/chrome/test_optimizations.html:67 (Diff revision 1) > + var markers = yield observeStyling(10); Would 5 frames be enough here? And less likely to lead to failures from, e.g. mouse movement triggering restyles? (In general, how reliable are these tests? I'd like to avoid introducing new intermittent oranges so we should retrigger these tests several times on each platform before landing.) ::: dom/animation/test/chrome/test_optimizations.html:69 (Diff revision 1) > + 'Compositor animations should never involve styling in main thread'); Animations running on the compositor should not update style on the main thread. ::: dom/animation/test/chrome/test_optimizations.html:70 (Diff revision 1) > + div.parentNode.removeChild(div); I think you can now just write: div.remove(); This is a newer part of the DOM spec that I think we've supported for a couple of years now. https://dom.spec.whatwg.org/#interface-childnode Likewise elsewhere in this file. ::: dom/animation/test/chrome/test_optimizations.html:78 (Diff revision 1) > + div.animationDuration = '200s'; I don't understand this test. What are we trying to test here? Does it matter if we do one extra restyle when we update the duration? ::: dom/animation/test/chrome/test_optimizations.html:96 (Diff revision 1) > + 'Compositor animations should involve only one styling process ' + 'Should only update style once after finish() is called'? ::: dom/animation/test/chrome/test_optimizations.html:96 (Diff revision 1) > + 'Compositor animations should involve only one styling process ' + Should we do the same test for main-thread animations? ::: dom/animation/test/chrome/test_optimizations.html:130 (Diff revision 1) > + { type: 'mousemove' }, window); It seems like this moves the mouse to the same point on every frame. Does that matter? Should the mouse position actually be moving on every frame? ::: dom/animation/test/chrome/test_optimizations.html:203 (Diff revision 1) > + div.parentNode.removeChild(div); I think we need to remove parentElement too. Likewise elsewhere in this file. ::: dom/animation/test/chrome/test_optimizations.html:232 (Diff revision 1) > + 'Bug XXXXXXX: Compositor animations in visibility hidden element ' + I think we should fill in the bug number here. ::: dom/animation/test/chrome/test_optimizations.html:246 (Diff revision 1) > + 'Bug XXXXXXX: Main-thread animations in visibility hidden element ' + Bug number here. This looks really good--I agree we want to have regression tests for this. I should probably have one more look after these comments are addressed since I didn't look too closely at the last few tests. One general comment is that there are lots of references to "no styling" but I think it's probably better to talk about not restyling. Also, I want to be sure this isn't going to introduce new intermittent failures. On a related note, if bug 1232563 sticks, we could add tests to this that paused animations don't cause restyles. Likewise for animations with a step function while we are within a step.

Comment on attachment 8704357 [details] MozReview Request: Bug 1235286 - Part 1: Add an argument to waitForAnimationFrames to run a task in each requestAnimationFrame callback. r=birtles Review request updated; see interdiff: https://reviewboard.mozilla.org/r/29641/diff/1-2/

Comment on attachment 8704358 [details] MozReview Request: Bug 1235286 - Part 2: Tests for animation optimizations. r?birtles Review request updated; see interdiff: https://reviewboard.mozilla.org/r/29643/diff/1-2/

Comment on attachment 8704358 [details] MozReview Request: Bug 1235286 - Part 2: Tests for animation optimizations. r?birtles Clearing review request. How can I see my comments on review board? It's hidden somewhere... (In reply to Brian Birtles (:birtles) from comment #6) > On a related note, if bug 1232563 sticks, we could add tests to this that > paused animations don't cause restyles. Likewise for animations with a step > function while we are within a step. This patch adds two test cases, one is for main-thread and the other is for compositor. But unfortunately the two tests fail now. Both animations cause three restyling process after pause() is called. I think, in case of compositor one, one restyling process might be acceptable, but there are three instead. Brian, any thought?

https://reviewboard.mozilla.org/r/29643/#review26473 > This doesn't seem right. I think you want the skip-if to apply to test_running_on_compositor.html, right? > > (Maybe that test passes on b2g now? If it doesn't, we should probably at least add a bug #.) Thanks. I did insert at wrong positions. > This is a bit vague. What exactly are we testing? Are we testing that we don't do unnecessary restyles? Or something else? > > We should name this file and test accordingly. Renamed to 'Tests restyles caused by animations'. > I think we need to check that compositor animations are enabled since we might turn them off on some platforms. > > Perhaps we could simply check animation.isRunningOnCompositor and if that's false, just return early. add_task_if_omta_enabled was added in this patch to check the preference value and return early if it's false. > Would 5 frames be enough here? And less likely to lead to failures from, e.g. mouse movement triggering restyles? > > (In general, how reliable are these tests? I'd like to avoid introducing new intermittent oranges so we should retrigger these tests several times on each platform before landing.) Yes, 5 frames enough. > I think you can now just write: > > div.remove(); > > This is a newer part of the DOM spec that I think we've supported for a couple of years now. > > https://dom.spec.whatwg.org/#interface-childnode > > Likewise elsewhere in this file. Thanks. I did not know the new spec. > I don't understand this test. What are we trying to test here? Does it matter if we do one extra restyle when we update the duration? My intention here is that we do not need to update styles when animation properties which don't change composed style at all is changed. In current implementation this test case passes, if we do update one or more restyles in thoese cases someday, we can eliminate it. > It seems like this moves the mouse to the same point on every frame. Does that matter? Should the mouse position actually be moving on every frame? Thanks. Actually with current implementation of event handling it does not matter that mouse position is moving or not, but moving mouse position will be much safer. > I think we should fill in the bug number here. Filed bug 1237454. This patch adds two test cases, one is for main-thread and the other is for compositor. But unfortunately the two new tests fail now. Both animations cause three restyling process after pause() is called. I think, in case of compositor one, one restyling process might be acceptable, but there are three instead. Wierd, but I am happy the tests catch these unpredictable behaviours. Brian, any thought?

(In reply to Hiroyuki Ikezoe (:hiro) from comment #9) > Comment on attachment 8704358 [details] > MozReview Request: Bug 1235286 - Part 2: Tests for animation optimizations. > r?birtles > > Clearing review request. > How can I see my comments on review board? It's hidden somewhere... I am sorry. I did not push 'Publish' button...

(In reply to Hiroyuki Ikezoe (:hiro) from comment #9) > Comment on attachment 8704358 [details] > MozReview Request: Bug 1235286 - Part 2: Tests for animation optimizations. > r?birtles > > Clearing review request. > How can I see my comments on review board? It's hidden somewhere... > > (In reply to Brian Birtles (:birtles) from comment #6) > > On a related note, if bug 1232563 sticks, we could add tests to this that > > paused animations don't cause restyles. Likewise for animations with a step > > function while we are within a step. > > This patch adds two test cases, one is for main-thread and the other is for > compositor. But unfortunately the two tests fail now. > Both animations cause three restyling process after pause() is called. I > think, in case of compositor one, one restyling process might be acceptable, > but there are three instead. > Brian, any thought? I guess it probably needs bug 1232577 to land since that should eliminate a number of cases of unnecessary restyling.

This all looks really good. For compositor animations, I wonder if it is better to check the OMTA pref, or just to check the 'isRunningOnCompositor' property? Maybe we should add an ok() check to each of the 'running on compositor' tests that checks that the animation is running on the compositor as we expect? That way if something prevents the animation from running on the compositor we will get a more helpful error message? That could be particularly useful if this test starts failing intermittently in automation.

(In reply to Brian Birtles (:birtles) from comment #13) > For compositor animations, I wonder if it is better to check the OMTA pref, > or just to check the 'isRunningOnCompositor' property? > > Maybe we should add an ok() check to each of the 'running on compositor' > tests that checks that the animation is running on the compositor as we > expect? That way if something prevents the animation from running on the > compositor we will get a more helpful error message? That could be > particularly useful if this test starts failing intermittently in automation. It's a really great idea! I will add the ok checks in each tests for animations on compositor.

(In reply to Hiroyuki Ikezoe (:hiro) from comment #9) > This patch adds two test cases, one is for main-thread and the other is for > compositor. But unfortunately the two tests fail now. > Both animations cause three restyling process after pause() is called. I > think, in case of compositor one, one restyling process might be acceptable, > but there are three instead. Oh, I think I misunderstood the question. My suggestion was not about testing restyling when pause() is called, but *after* it has been called and we are actually paused. When we call pause() it is expected we will get at least two restyles and maybe more since we don't pause immediately. However, after we complete the pause (i.e. animation.ready has resolved), we shouldn't get any more restyles. We might still need bug 1232577 to land before that works, I'm not sure.

A try result revealed that opacity animations in visibility:hidden element or scrolled out element are running on compositor! It's hard to believe and it's worth to investigate the reason. https://treeherder.mozilla.org/#/jobs?repo=try&revision=65cdc3923e7a&selectedJob=15199654 I will handle these cases in each bug respectively, and am going to remove these test cases in this bug for now.

(In reply to Brian Birtles (:birtles, away 9~11 Jan) from comment #15) > (In reply to Hiroyuki Ikezoe (:hiro) from comment #9) > > This patch adds two test cases, one is for main-thread and the other is for > > compositor. But unfortunately the two tests fail now. > > Both animations cause three restyling process after pause() is called. I > > think, in case of compositor one, one restyling process might be acceptable, > > but there are three instead. > > Oh, I think I misunderstood the question. My suggestion was not about > testing restyling when pause() is called, but *after* it has been called and > we are actually paused. > > When we call pause() it is expected we will get at least two restyles and > maybe more since we don't pause immediately. However, after we complete the > pause (i.e. animation.ready has resolved), we shouldn't get any more > restyles. We might still need bug 1232577 to land before that works, I'm not > sure. Thanks! animation.ready makes the test pass!

A try run on desktop builds. This new test did not fail on the debug builds. https://treeherder.mozilla.org/#/jobs?repo=try&revision=37536b010b53

Comment on attachment 8704357 [details] MozReview Request: Bug 1235286 - Part 1: Add an argument to waitForAnimationFrames to run a task in each requestAnimationFrame callback. r=birtles Review request updated; see interdiff: https://reviewboard.mozilla.org/r/29641/diff/2-3/

Comment on attachment 8704358 [details] MozReview Request: Bug 1235286 - Part 2: Tests for animation optimizations. r?birtles Review request updated; see interdiff: https://reviewboard.mozilla.org/r/29643/diff/2-3/

(In reply to Hiroyuki Ikezoe (:hiro) from comment #20) > Comment on attachment 8704358 [details] > MozReview Request: Bug 1235286 - Part 2: Tests for animation optimizations. > r?birtles > > Review request updated; see interdiff: > https://reviewboard.mozilla.org/r/29643/diff/2-3/ I did drop a test case for bug 1235478 because the test case causes intermittent failure without the fix for bug 1235478.

Comment on attachment 8704358 [details] MozReview Request: Bug 1235286 - Part 2: Tests for animation optimizations. r?birtles https://reviewboard.mozilla.org/r/29643/#review28105

I did totally forgot to disable tests which failed on Android and B2G in comment #16. I did want to disable those tests only on Android and B2G but current mochitest frame work does not allow us to disable each test respectively. So I just comment those tests out here. I think it's OK because those tests are 'todo' for now.

Comment on attachment 8709811 [details] [diff] [review] Disable some tests failure on Android and B2G Review of attachment 8709811 [details] [diff] [review]: ----------------------------------------------------------------- ::: dom/animation/test/chrome/test_restyles.html @@ +213,5 @@ > > + /* > + This opacity animation IS running on compositor even if associated element > + is scrolled out on Android. > + So we disable this test for now until we fix bug 1166500 or a follow-up bug. "Disabled for now since, on Android, the opacity animation runs on the compositor even if it is scrolled out of view. We will fix this in bug 1166500 or a follow-up bug." @@ +254,5 @@ > > + /* > + This opacity animation IS running on compositor even if associated element > + has visibility:hidden style on Android and B2G. > + So we disable this test for now until we fix bug 1237454 or a follow-up bug. "Disabled for now since, on Android and B2G, the opacity animation runs on the compositor even if the associated element has visibility:hidden. We will fix this in bug 1237454 or a follow-up bug."

https://hg.mozilla.org/integration/mozilla-inbound/rev/8e7c3457b7f6 https://hg.mozilla.org/integration/mozilla-inbound/rev/6eff7d8d2aa1 https://hg.mozilla.org/integration/mozilla-inbound/rev/c5cac160d4fe

https://hg.mozilla.org/mozilla-central/rev/8e7c3457b7f6 https://hg.mozilla.org/mozilla-central/rev/6eff7d8d2aa1 https://hg.mozilla.org/mozilla-central/rev/c5cac160d4fe

:hiro, I am working with :wcosta on getting osx tests running in taskcluster (a new continuous integration system to replace our aging buildbot setup). One issue we see is that while running mochitest-chrome, we get a failure where css animations are updating the style on the main thread- I see you wrote test code for this, maybe you can help shed light on what this is testing and why we might be having troubles on osx 10.10: https://public-artifacts.taskcluster.net/bxNhzYE6QIaRoaFnT-xx3Q/0/public/logs/live_backing.log [taskcluster:error] 08:41:58 INFO - 794 INFO TEST-START | dom/animation/test/chrome/test_restyles.html [taskcluster:error] 08:41:58 INFO - Not taking screenshot here: see the one that was previously logged [taskcluster:error] 08:41:58 INFO - 795 INFO SpawnTask.js | Entering test restyling_for_main_thread_animations [taskcluster:error] 08:41:58 INFO - 796 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | undefined assertion name [taskcluster:error] 08:41:58 INFO - 797 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | CSS animations running on the main-thread should update style on the main thread [taskcluster:error] 08:41:58 INFO - 798 INFO SpawnTask.js | Leaving test restyling_for_main_thread_animations [taskcluster:error] 08:41:58 INFO - 799 INFO SpawnTask.js | Entering test no_restyling_for_compositor_animations [taskcluster:error] 08:41:58 INFO - 800 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | undefined assertion name [taskcluster:error] 08:41:58 INFO - 801 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | CSS animations running on the compositor should not update style on the main thread [taskcluster:error] 08:41:58 INFO - 802 INFO SpawnTask.js | Leaving test no_restyling_for_compositor_animations [taskcluster:error] 08:41:58 INFO - 803 INFO SpawnTask.js | Entering test no_restyling_for_compositor_transitions [taskcluster:error] 08:41:58 INFO - 804 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | undefined assertion name [taskcluster:error] 08:41:58 INFO - 805 INFO TEST-UNEXPECTED-FAIL | dom/animation/test/chrome/test_restyles.html | CSS transitions running on the compositor should not update style on the main thread - got 3, expected +0 [taskcluster:error] 08:41:59 INFO - SimpleTest.is@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:268:5 [taskcluster:error] 08:41:59 INFO - no_restyling_for_compositor_transitions@chrome://mochitests/content/chrome/dom/animation/test/chrome/test_restyles.html:123:5 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:69:15 [taskcluster:error] 08:41:59 INFO - Async*next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:104:45 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:73:7 [taskcluster:error] 08:41:59 INFO - Async*next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:104:45 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:73:7 [taskcluster:error] 08:41:59 INFO - co/<@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:58:5 [taskcluster:error] 08:41:59 INFO - co@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:54:10 [taskcluster:error] 08:41:59 INFO - toPromise@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:122:60 [taskcluster:error] 08:41:59 INFO - next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:103:19 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:73:7 [taskcluster:error] 08:41:59 INFO - Async*next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:104:45 [taskcluster:error] 08:41:59 INFO - Async*next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:104:45 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:73:7 [taskcluster:error] 08:41:59 INFO - co/<@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:58:5 [taskcluster:error] 08:41:59 INFO - co@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:54:10 [taskcluster:error] 08:41:59 INFO - setTimeout handler*SimpleTest_setTimeoutShim@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:622:12 [taskcluster:error] 08:41:59 INFO - add_task@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:269:7 [taskcluster:error] 08:41:59 INFO - @chrome://mochitests/content/chrome/dom/animation/test/chrome/test_restyles.html:84:3 [taskcluster:error] 08:41:59 INFO - waitForPaints@chrome://mochikit/content/tests/SimpleTest/paint_listener.js:73:5 [taskcluster:error] 08:41:59 INFO - waitForPaints/<@chrome://mochikit/content/tests/SimpleTest/paint_listener.js:61:22 [taskcluster:error] 08:41:59 INFO - setTimeout handler*SimpleTest_setTimeoutShim@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:622:12 [taskcluster:error] 08:41:59 INFO - paintListener@chrome://mochikit/content/tests/SimpleTest/paint_listener.js:28:7 [taskcluster:error] 08:41:59 INFO - EventListener.handleEvent*@chrome://mochikit/content/tests/SimpleTest/paint_listener.js:31:3 [taskcluster:error] 08:41:59 INFO - @chrome://mochikit/content/tests/SimpleTest/paint_listener.js:1:2 [taskcluster:error] 08:41:59 INFO - 806 INFO SpawnTask.js | Leaving test no_restyling_for_compositor_transitions [taskcluster:error] 08:41:59 INFO - 807 INFO SpawnTask.js | Entering test no_restyling_when_animation_duration_is_changed [taskcluster:error] 08:41:59 INFO - 808 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | undefined assertion name [taskcluster:error] 08:41:59 INFO - Not taking screenshot here: see the one that was previously logged [taskcluster:error] 08:41:59 INFO - 809 INFO TEST-UNEXPECTED-FAIL | dom/animation/test/chrome/test_restyles.html | Animations running on the compositor should not update style on the main thread - got 1, expected +0 [taskcluster:error] 08:41:59 INFO - SimpleTest.is@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:268:5 [taskcluster:error] 08:41:59 INFO - no_restyling_when_animation_duration_is_changed@chrome://mochitests/content/chrome/dom/animation/test/chrome/test_restyles.html:139:5 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:69:15 [taskcluster:error] 08:41:59 INFO - Async*next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:104:45 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:73:7 [taskcluster:error] 08:41:59 INFO - Async*next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:104:45 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:73:7 [taskcluster:error] 08:41:59 INFO - co/<@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:58:5 [taskcluster:error] 08:41:59 INFO - co@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:54:10 [taskcluster:error] 08:41:59 INFO - toPromise@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:122:60 [taskcluster:error] 08:41:59 INFO - next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:103:19 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:73:7 [taskcluster:error] 08:41:59 INFO - Async*next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:104:45 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:73:7 [taskcluster:error] 08:41:59 INFO - Async*next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:104:45 [taskcluster:error] 08:41:59 INFO - Async*next@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:104:45 [taskcluster:error] 08:41:59 INFO - onFulfilled@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:73:7 [taskcluster:error] 08:41:59 INFO - co/<@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:58:5 [taskcluster:error] 08:41:59 INFO - co@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:54:10 [taskcluster:error] 08:41:59 INFO - setTimeout handler*SimpleTest_setTimeoutShim@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:622:12 [taskcluster:error] 08:41:59 INFO - add_task@chrome://mochikit/content/tests/SimpleTest/SpawnTask.js:269:7 [taskcluster:error] 08:41:59 INFO - @chrome://mochitests/content/chrome/dom/animation/test/chrome/test_restyles.html:84:3 [taskcluster:error] 08:41:59 INFO - waitForPaints@chrome://mochikit/content/tests/SimpleTest/paint_listener.js:73:5 [taskcluster:error] 08:41:59 INFO - waitForPaints/<@chrome://mochikit/content/tests/SimpleTest/paint_listener.js:61:22 [taskcluster:error] 08:41:59 INFO - setTimeout handler*SimpleTest_setTimeoutShim@chrome://mochikit/content/tests/SimpleTest/SimpleTest.js:622:12 [taskcluster:error] 08:41:59 INFO - paintListener@chrome://mochikit/content/tests/SimpleTest/paint_listener.js:28:7 [taskcluster:error] 08:41:59 INFO - EventListener.handleEvent*@chrome://mochikit/content/tests/SimpleTest/paint_listener.js:31:3 [taskcluster:error] 08:41:59 INFO - @chrome://mochikit/content/tests/SimpleTest/paint_listener.js:1:2 [taskcluster:error] 08:41:59 INFO - 810 INFO SpawnTask.js | Leaving test no_restyling_when_animation_duration_is_changed [taskcluster:error] 08:41:59 INFO - 811 INFO SpawnTask.js | Entering test only_one_restyling_after_finish_is_called [taskcluster:error] 08:41:59 INFO - 812 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | undefined assertion name [taskcluster:error] 08:41:59 INFO - 813 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | Animations running on the compositor should only update style once after finish() is called [taskcluster:error] 08:41:59 INFO - 814 INFO SpawnTask.js | Leaving test only_one_restyling_after_finish_is_called [taskcluster:error] 08:41:59 INFO - 815 INFO SpawnTask.js | Entering test no_restyling_mouse_movement_on_finished_transition [taskcluster:error] 08:41:59 INFO - 816 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | Bug 1219236: Finished transitions should never cause restyles when mouse is moved on the animations [taskcluster:error] 08:41:59 INFO - 817 INFO SpawnTask.js | Leaving test no_restyling_mouse_movement_on_finished_transition [taskcluster:error] 08:41:59 INFO - 818 INFO SpawnTask.js | Entering test no_restyling_mouse_movement_on_finished_animation [taskcluster:error] 08:41:59 INFO - 819 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | Bug 1219236: Finished animations should never cause restyles when mouse is moved on the animations [taskcluster:error] 08:41:59 INFO - 820 INFO SpawnTask.js | Leaving test no_restyling_mouse_movement_on_finished_animation [taskcluster:error] 08:41:59 INFO - 821 INFO SpawnTask.js | Entering test no_restyling_compositor_animations_out_of_view_element [taskcluster:error] 08:41:59 INFO - 822 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | undefined assertion name [taskcluster:error] 08:41:59 INFO - 823 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | Animations running on the compositor in an out-of-view element should never cause restyles [taskcluster:error] 08:41:59 INFO - 824 INFO SpawnTask.js | Leaving test no_restyling_compositor_animations_out_of_view_element [taskcluster:error] 08:41:59 INFO - 825 INFO SpawnTask.js | Entering test no_restyling_main_thread_animations_out_of_view_element [taskcluster:error] 08:42:00 INFO - 826 INFO TEST-PASS | dom/animation/test/chrome/test_restyles.html | Animations running on the main-thread in an out-of-view element should never cause restyles ....

I saw the failure a few times on my colleague's mac book before, but I did not investigate further in detail at that time because we've never seen the failure on our automation servers. The characteristic of restyles on MacOSX (maybe only 10.10?) seems to be something different from other platforms. Anyway, it should be fixed, I will tackle it in a new bug. Unfortunately I have no mac machine now so it will take some time. If the new taskcluster system is an urgent job, I will figure out a tentative solution.