1132782 - getAnimationPlayers should return animations that have finished and are not filling forwards

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect)

Description

[Brian Birtles (:birtles, Feb 26~ parental leave)]

getAnimationPlayers() currently doesn't return animations that haven't finished and are not filling forwards. This was done to reduce memory pressure for script-based animations where authors may fire off many animations over time and forget about them such that the number of animations grows in an unbounded fashion.

However, for devtools we often need to be able to inspect and manipulate animations that have finished. They often only exist for a short time so they can be difficult to catch.

For CSS Animations, we don't have the same issue as script-based animations since firing successive animations on the same element requires resetting the style. In order to retrigger an animation the author has to explicitly the old animation (or explicitly append to the list of animation names in which case they get what they asked for--i.e. increased resource usage).

For CSS animations, at least, I think we could make getAnimationPlayers return all finished animations still contained in the animation-name property. I proposed this to Google and they opposed it.

For CSS transitions and script-generated animations, I'm not sure. One possibility is to have the observer API report all generated animations and have devtools hold onto them to keep them alive.

Comment 1

[Patrick Brosset <:pbro>]

This is super useful for devtools because it would make it possible for us to display present AND past animations in the animation panel, when selecting a node, and would therefore be a way for users to restart finished animations in order to tweak them.
A lot of animations on the web are subtle, quick changes that are hard to work on using devtools, so this would help a lot.

Comment 2

[Jonathan Watt [:jwatt]]

If the Google guys aren't happy to have getAnimationPlayers return all finished animations still contained in the animation-name property, perhaps we could have a mechanism for "re-applying" a player to an element via script? That way devtools can keep hold of the animation and (in principle, once we implement some missing functionality) then apply it again on demand if requested by the user.

It seems like we'd want a way to tell if an AnimationPlayer is currently applying though, perhaps by nulling out Animation.target when in is finished?

It also seems like the player should re-appear in the list returned by getAnimationPlayers if the player's startTime in modified so that it should currently be applying or should apply at some point in the future.

Comment 3

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to Jonathan Watt [:jwatt] from comment #2)
> If the Google guys aren't happy to have getAnimationPlayers return all
> finished animations still contained in the animation-name property, perhaps
> we could have a mechanism for "re-applying" a player to an element via
> script? That way devtools can keep hold of the animation and (in principle,
> once we implement some missing functionality) then apply it again on demand
> if requested by the user.

They should be able to already do this just by calling play() again. Basically, they just need to set the time to somewhere before or during the active interval. For transitions, which get cancelled when they finish, you need to call play() or set a startTime in order to get out of the idle state back into the running state.

> It seems like we'd want a way to tell if an AnimationPlayer is currently
> applying though, perhaps by nulling out Animation.target when in is finished?

You can just check player.source.computedTiming.timeFraction. If it's null, it's not applying.

> It also seems like the player should re-appear in the list returned by
> getAnimationPlayers if the player's startTime in modified so that it should
> currently be applying or should apply at some point in the future.

Yes, that should happen automatically.

Comment 4

[Jonathan Watt [:jwatt]]

If we're not going to carry out the change as described in the Summary line, is this WONTFIX? Or is there some other work that we should do here?

Comment 5

[Patrick Brosset <:pbro>]

My input on this is we can close the bug. I don't think we're going to need this after all for devtools.