Bug 67959 – Switching to previously-active tab disrupts CSS animations

• Component: Layout and Rendering
• Status: UNCONFIRMED

[Daniel Morgan]

In Safari 5.1 (6534.50), switch to a different tab during an HTML animation (Canvas). When that tab is returned to, the animation behaves differently.

[Alexey Proskuryakov]

I see that the animation is played at a much faster rate for a while after switching back to the tab with this site. In Firefox, the animation isn't stopped in background, and doesn't speed up after activating a tab.

Not sure if this is necessarily a WebKit bug.

[Matthew Delaney]

By the platform choice of 10.6, did you mean to say that this bug only reproduces on 10.6?

Which canvas animations are you referring to? Also, since canvas animations are always driven by the firing of dom timers, the only thing I could imagine WebKit doing improperly that would cause this behavior would be giving timers sooner than requested. Furthermore, firing timers sooner would only cause this issue if the animation code of the site relied on getting the timers at the requested intervals - which is something that's not guaranteed. Thus, my guess is that the animation code of the site is the reason for the "faster rate". Though, if we're also consistently firing off timers faster than requested, then that sounds like a legitimate issue to investigate.

[Simon Fraser (smfr)]

I don't see any canvas animations on http://www.sinorwin.com/
I do see CSS animations.

[Dean Jackson]

> document.querySelector("canvas");
null

[Dean Jackson]

I haven't investigated completely, but I suspect the bug could be that the HYPE heartbeat doesn't know that the animations paused for a while. It does a difference from an animationStartTime which might be out of date.

It would be nice to get a reduction here. I can't see a bug in WebKit at the moment.