1270031 - Paused animation is unexpectedly started when the timing function is step-start.

Status: RESOLVED INVALID

(Core :: DOM: Animation, defect)

Description

[James Holderness]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160503030421

Steps to reproduce:

(1) Create an animation with the animation-play-state set to paused.
(2) Set the animation-timing-function to step-start.
(3) Create a 'to' keyframe which alters some property value (e.g. setting the text color).

Example: https://jsfiddle.net/83888h9u/


Actual results:

The 'to' keyframe takes effect, and the property is changed (in the given example, the color changes to red), even though the animation is paused.



Expected results:

The 'to' keyframe shouldn't take effect, since the animation isn't running (in the given example, the color should remain blue).

This used to work as expected (at least as recently as version 45.0.2), but is now broken in the nightly build.

Comment 1

[Loic]

Attachment: 1270031.html

Comment 2

[Loic]

Regression range:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=170e0a
c6b29219303c42209c9df5f4775fcbf951&tochange=fe8bfb08d27387b0d584ee18b9ce6541a8e0
3884

Daisuke Akatsuka — Bug 1248532 - Part 1: steps-start does not produce correct value at the beginning of the interval. r=birtles

Comment 3

[Brian Birtles (:birtles)]

(In reply to James Holderness from comment #0)
> Expected results:
> 
> The 'to' keyframe shouldn't take effect, since the animation isn't running
> (in the given example, the color should remain blue).
> 
> This used to work as expected (at least as recently as version 45.0.2), but
> is now broken in the nightly build.

This behavior has changed because the old behavior was incorrect. For a step-start timing function, the step occurs at t=0 such that at t=0 we are already at the top of the first step. There are further details in bug 1248532.

Even though the animation is paused, it is paused at t=0 so it is producing the correct result. Note that our behavior here matches Chrome.

(Also note, if you really want to get the animation to *not* step up, you can add an small delay--however, that won't work in Chrome, yet. The spec says that in the delay phase with a backwards fill you don't step up.)

Marking as invalid but please reopen if you have further information to suggest this is not correct.

Comment 4

[James Holderness]

I didn't find the specification very clear on the subject, but my interpretation of the expected behaviour came from the definition of the animationstart event in section 5.2 of the editors draft (https://drafts.csswg.org/css-animations-1/#event-animationevent):

> The animationstart event occurs at the start of the animation. If there is
> an animation-delay then this event will fire once the delay period has 
> expired. A negative delay will cause the event to fire with an elapsedTime 
> equal to the absolute value of the delay; in this case the event will fire 
> whether animation-play-state is set to running or paused. 

The phrase "in this case the event will fire whether animation-play-state is set to running or paused" made it sound like in other cases (i.e. a non-negative delay), the event wouldn't fire if the animation-play-state was paused.

Comment 5

[Brian Birtles (:birtles)]

That last sentence is a bit odd. However, the dispatch of events doesn't define when the animation value is applied. For example, an animation with a positive delay and backwards fill still affects the computed style despite the fact that the animationstart event isn't yet dispatched.

Likewise, we'll dispatch an animationstart event even for a paused animation (which I believe is what the spec is trying to imply there).

The fact that we didn't used to display the top of the stop with 'step-start' on a paused animation at t=0 wasn't because the animation wasn't considered to be applied at that point, but simply because of the interpretation we decided to take on when step-start steps up. That has since been clarified in Web Animations so we've updated our implementation of step timing functions to match.

Comment 6

[James Holderness]

Other than the backwards fill case, I wouldn't have expected the animation to apply or the event to be dispatched, regardless of the timing function. However, checking now I see that Firefox has always behaved that way (other than the step-start case) so I can understand not wanting to change that, and I see now why the previous step-start behaviour was considered a bug.

Thank you for taking the time to clarify the situation.