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

RESOLVED WONTFIX

Status

()

RESOLVED WONTFIX
4 years ago
4 years ago

People

(Reporter: birtles, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.
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.
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.
(Reporter)

Comment 3

4 years ago
(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.
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?
Flags: needinfo?(bbirtles)
My input on this is we can close the bug. I don't think we're going to need this after all for devtools.
(Reporter)

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Flags: needinfo?(bbirtles)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.