Pause animation when tab loses focus. Fixes bug #9381

[louisremi]

Fixes http://bugs.jquery.com/ticket/9381

Animation frameworks have to deal with the problems that occur when requestAnimationFrame powers the animation loop and the tab loses focus. The general idea is to artificially limit the interval between two animation ticks.
This was illustrated in Seth Ladd's "Intro to HTML5 Game Development" during Google I/O 2011: http://io-2011-html5-games-hr.appspot.com/#36
He calculates the time delta between two animation ticks and limit this value to 60ms

var dT = Math.min( now - prevNow, 60 );

The way jQuery animations work is more complex than Seth's ones, as animations aren't based on the time delta between the previous tick and the current one, but between the beginning of the animation (startTime) and the current one. The only way to limit the interval between two ticks is to move the value of startTime forward in time.

With this 5loc patch, jQuery detects when the interval takes longer than usual and moves startTime accordingly to effectively pause the animation. Once the tab is focused again, the animation continues where it stopped.

[jaubourg]

Let me get this straight: we change how animations in jQuery are scheduled because Firefox cannot properly handle timeouts when tab is not focussed? I'm sorry but I find that saddening to say the least.

[louisremi]

The problem will be the same in every browser implementing requestAnimationFrame. It's just that switching back to setInterval is not the solution, as it won't work in Firefox (other browsers could adopt the same behavior).
I don't think this raf flag was a good idea anyway. I doubt much developers would have ever heard about it and really understood what it was for.
This patch fixes a problem inherent to requestAnimationFrame, without requiring devs to worry about it :-)

[jaubourg]

Sadly they still do: they cannot rely on animations callbacks to be fired after a reasonable amount of time. Even worse, in FF, setTimeout's contract of being called as soon as possible after the delay is over is broken when tab is not focussed which is a bug, not a feature (why on earth would non-rendering tasks be delayed is beyond me): it becomes impossible to schedule anything in a page properly -- at least as properly as we already can -- and this bug will have to be fixed, that much is obvious.

Now, to the task at hand, we're not talking about choosing between raf and setInterval, but about architecturing the animation system properly (that is separate rendering and scheduling). The current situation only demonstrates that raf should be used for rendering alone and scheduling should be done in parallel, with timers, and that FF decision to delay timers is as wrong as it can get. Bad design decisions are occuring right now and it's not time to "guess" a proper threshold to detect if we're being delayed or not, it's time to state that, while raf not being fired is fine and makes sense, delaying timers is a non-sense.

[louisremi]

Apparently Chrome already behaves in the same way: http://code.google.com/p/chromium/issues/detail?id=66078
And the minimum interval in Firefox is actually 1s, not 250ms: https://bugzilla.mozilla.org/show_bug.cgi?id=633421

[jaubourg]

Then I give up on web development altogether because it'll become a game of guessing when Mr. Browser will be kind enough to fire my callbacks. Delaying timers should be a choice, not forced down our throat in circumstances the web app has no control over. I've rarely been as infuriated against browser devs as I am right now.

Nothing against you louisremi, mind you, you're just the messenger ;)

[curiousdannii]

Yet more evidence that the Chrome devs only care about the web if the web is obedient to them...

Anyone know if worker timers are affected?

[Ivanca]

Why do callbacks of animations do -actually- wait for the animation to finish? Inside jQuery it should be just a timeout that stops the animation, move the object to the final position and then executes the callback.

I always do this because animation callbacks are not reliable (specially when using the jQuery easing plugin)

[louisremi]

No, animation callbacks ARE reliable because they are not fired by a setTimeout, but when the animation is actually finished.
Only a reduced test-case could prove this wrong.

[dmethvin]

I'm going to close this PR since it's likely we'll need to rethink and rework the animation timer/rAF issue when it finally lands.