Open samthor opened 9 years ago
Yup, that would be fine too, just some effort in finding where to call that. We've got to keep track of the players we want to later remove.
Some notes after chatting to Chrome team-
IOWA.Elements.Nav
.This is interesting to say the least! I'd like to better understand the intended usage pattern(s) of the player stuff, and whether that changes between native an polyfill world. TBH, I consider IOWA's usage of the API fairly straightforward and what may developers will also attemp. If developers are expected to do a ton of bookkeeping in a SPA, that seems like razors and knives everywhere.
I spent some time with @devnook and @paullewis memory profiling IOWA for leaks this morning. We discovered a lot of instances of detached DOM nodes (sourced from template stamping) that weren't getting correctly cleaned up, but nothing in our traces suggested it was an issue with the animation polyfills or player. I'd be super interested in how we arrived at the animation leaks data from above :)
I tried to rewrite page animations to avoid using fill: "forward", but it seems not possible at the moment. It works well in Chrome, but in FF and Safari the animated target looses its animated state at the end of animation (but before onfinish callback is called), making it impossible to properly finish an animation without flickering (e.g. hide content, update colors etc).
Every Web Animation that is being played with a timing option
fill: 'forwards'
and then later forgotten about is essentially leaking a newAnimationPlayer
.For instance, navigating to many different pages is going to leave a big trail of each animation transition used to get there. Ostensibly the benefit here is that you can pop the animations to get back to the previous state.
We should either-
1) remove
fill: 'forwards'
(or'both'
) where it doesn't make sense 2) have a way to pop/clear players once we're confidently done with them