In the attached test case, we pause an animation and seek it but nothing is rendered. It should render a box with width: 75px, and height: 100px. Inspecting the console output, however, reveals that the computed style is updated. If we wait for anim.ready before pausing and seeking then it works.

It seems like the issue is that nsStyleSet::GetContext doesn't pick up the animation rule in the case where we *only* have script generated animations. This patch is a hacky fix to demonstrate the problem. We probably need to refactor nsAnimationManager::CheckAnimationRule so that it simply updates the state of CSS animations. Then we should have a separate step that fetches the animation rule for either case.

As for an automated test, we *could* use a reftest, but I can also reproduce this by calling getComputedStyle in attachment 8716131 [details] some time later... perhaps on the next frame. Then I get back "0px" for the width.

Apparently Chrome got a bug report that the following test works in Firefox but not in Chrome: https://jsfiddle.net/ur1cp5d6/ Upon investigation, this test should *not* work and fixing this bug makes us behave like Chrome.

Without this patch, when we have script generated animations but *no* CSS animations, nsStyleSet::GetContext will not use the updated animation rule.

https://hg.mozilla.org/integration/mozilla-inbound/rev/ab454c4469b7 https://hg.mozilla.org/integration/mozilla-inbound/rev/08f313ec397a

https://hg.mozilla.org/mozilla-central/rev/ab454c4469b7 https://hg.mozilla.org/mozilla-central/rev/08f313ec397a