Ubuntu VM 12.04 x64 Mulet b2g-inbound opt test mochitest-1 on 2014-08-06 23:49:34 PDT for push 8542bcd9ab6d slave: tst-linux64-spot-696 https://tbpl.mozilla.org/php/getParsedLog.php?id=45397602&tree=B2g-Inbound { 00:10:07 INFO - 2712 INFO TEST-START | /tests/dom/alarm/test/test_alarm_permitted_app.html 00:10:07 INFO - 2713 INFO TEST-OK | /tests/dom/alarm/test/test_alarm_permitted_app.html | took 224ms 00:10:07 INFO - 2714 INFO TEST-START | /tests/dom/animation/test/css-integration/test_animations-dynamic-changes.html 00:10:07 INFO - 2715 INFO dumping last 1 message(s) 00:10:07 INFO - 2716 INFO if you need more context, please use SimpleTest.requestCompleteLog() in your test 00:10:07 INFO - 2717 INFO TEST-PASS | /tests/dom/animation/test/css-integration/test_animations-dynamic-changes.html | - : Elided 4 passes or known failures. 00:10:07 INFO - 2718 INFO TEST-UNEXPECTED-FAIL | /tests/dom/animation/test/css-integration/test_animations-dynamic-changes.html | Player state is preserved when interleaving animations in list - Player state is preserved when interleaving animations in list: assert_true: Interleaved player starts later than existing players expected true got false 00:10:07 INFO - TEST-INFO | expected PASS 00:10:07 INFO - 2719 INFO TEST-OK | /tests/dom/animation/test/css-integration/test_animations-dynamic-changes.html | took 367ms }

I'm not sure what's causing this or why it's happening on Mulet only or why it only started recently. The only animation-related change I know of that corresponds to this timeframe is bug 996796 but that doesn't seem too likely. I wonder if the refresh driver operates differently in Mulet and we're getting the same timestamp back even after calling requestAnimationFrame. I know when we switch internal timers we can end up reporting the same timestamp twice (since we clamp the time to make sure it doesn't go backwards).

Mass-closing intermittent-failure bugs filed by me, that have not occurred recently and do not have the leave-open keyword set.

(In reply to Brian Birtles (:birtles) from comment #15) > I'm not sure what's causing this or why it's happening on Mulet only or why > it only started recently. The only animation-related change I know of that > corresponds to this timeframe is bug 996796 but that doesn't seem too likely. > > I wonder if the refresh driver operates differently in Mulet and we're > getting the same timestamp back even after calling requestAnimationFrame. I > know when we switch internal timers we can end up reporting the same > timestamp twice (since we clamp the time to make sure it doesn't go > backwards). Do you know if this is still an issue? I'm hitting this when enabling the vsync refresh driver: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ceca6ab44cce Or whats the proper fix to this?

Looks like you're hitting a couple of different failures than this bug. Just looking at the first one, "Animations are removed from the start of the list while preserving the state of existing players - Animations are removed from the start of the list while preserving the state of existing players: assert_true: Remaining player preserves startTime expected true got false" Does changing line 117 to <= fix that failure? i.e. making the condition: players[0].startTime <= players[0].timeline.currentTime If so, then I'd suggest we rewrite that test to store the startTime of one of the players before updating the CSS and checking that it doesn't change. If, however, players[0].startTime is actually greater than players[0].timeline.currentTime then we have a problem.

Waiting on try and will retrigger - https://treeherder.mozilla.org/#/jobs?repo=try&revision=8bae6a4b2971