When testing OMTA (bug 964646) I came across a situation where unpausing a CSS animation during its delay phase fails to update the compositor thread. The code to produce this is as follows: new_div("animation: anim2 1s 0.5s ease-out"); yield waitForPaints(); omta_is("opacity", 1, RunningOn.Either, "delay and play-state delay test at 0ms"); advance_clock(400); omta_is("opacity", 1, RunningOn.Either, "delay and play-state delay test at 400ms"); gDiv.style.animationPlayState = "paused"; yield waitForPaintsFlushed(); advance_clock(100); omta_is("opacity", 1, RunningOn.Either, "delay and play-state delay test at 500ms"); advance_clock(500); omta_is("opacity", 1, RunningOn.Either, "delay and play-state delay test at 1000ms"); gDiv.style.animationPlayState = "running"; yield waitForPaintsFlushed(); advance_clock(100); omta_is("opacity", 0, RunningOn.Compositor, "delay and play-state delay test at 1100ms"); advance_clock(100); omta_is_approx("opacity", gTF.ease_out(0.1), RunningOn.Compositor, 0.01, "delay and play-state delay test at 1200ms"); gDiv.style.animationPlayState = "paused"; yield waitForPaintsFlushed(); advance_clock(100); omta_is_approx("opacity", gTF.ease_out(0.1), RunningOn.Either, 0.01, "delay and play-state delay test at 1300ms"); done_div(); (For the definitions of those methods and animations, see http://dxr.mozilla.org/mozilla-central/source/layout/style/test/test_animations_omta.html) I've been trying to create a reduced standalone test case of this but haven't succeeded yet. One test I made failed for me about 3 times but mostly works. I plan to debug this using a suitably reduced version of the above code and let bug 964646 provide the regression test for this bug.

On further investigation, the bug is with the test case above. When a delay is involved, the test needs to wait for paints to happen so the animation can be sent to the compositor.