Scroll-Driven Animations in Safari hang after traversing the browser’s history … unless you have Web Inspector open

[bramus]

Now here’s a weird situation … in Safari, when traversing the history, animations are not restored correctly. They just hang. What’s even weirder is that from the moment you try to debug this – by opening Web Inspector - the issue is gone.

https://github.com/flackr/scroll-timeline/assets/213073/ec0adb0c-bda1-48a6-842b-41f639efbdbe

By the looks of it the animations get paused, but never tick forwards. I’m guessing there’s some caching issue going on, which needs investigation.

[bramus]

I’ve narrowed this down to a Page Cache (BFCache) problem.

On first page load, when animationstart events get triggered, the original animation gets paused, and the ProxyAnimation gets played instead. This ProxyAnimation instance is stored in a cache (a WeakMap called proxyAnimations) so that it doesn’t get rebuilt whenever an animation restarts as you scroll up/down on the page.

https://github.com/flackr/scroll-timeline/blob/5fab1816ad4f13e2cef3cd27ce6b243027a4970f/src/scroll-timeline-css.js#L168-L171

Internally, upon calling proxyAnimation.play(); a chain of calls happens, eventually leading to addAnimation being called to internally store the animation.

https://github.com/flackr/scroll-timeline/blob/5fab1816ad4f13e2cef3cd27ce6b243027a4970f/src/scroll-timeline-base.js#L197-L209

It’s in this addAnimation where things go wrong. In that function, there’s a bailout mechanism: if the animation is already there, just return. It’s that part that doesn’t play nice with BFCache …

• Upon first page load, this logic works fine: The animation isn’t present in the list of animations, so it gets added and successively tickAnimation gets called to get it started.
• When loading the page from the BFCache, this does not work fine. The animation is already present and the early return kicks in. The animation doesn’t tick.

---

So now, that we know what’s going on, how can we fix this?

I’ve tried to manually tick the animation forwards just before the early return in addAnimation, but this has some other side effects such as it constantly being re-triggered when the animation restarts as the element re-enters the scrollport. Instead of happening all the time, this manual ticking forwards should only happen in case the ProxyAnimation was loaded from the proxyAnimations cache. That would require passing a flag all the way down to addAnimations, so that it would know.

To not fiddle with the polyfill’s internals too much, I came up with another workaround: simply clear the proxyAnimations cache when the page gets unloaded using the unload event. That way, when going back, new ProxyAnimation instances get created and all works fine :)

I’m about to file a PR with this change.