Re: [RequestAnimationFrame] suspending callbacks in background pages

On 7/6/11 5:56 PM, Cameron McCormack wrote:
> James was saying on the call today that he hasn’t encountered content so
> far that would be tripped up by not invoking the callback in the
> background tab.
>
> Boris or Rob, do you have any further thoughts on whether it would be
> safe to mandate not invoking the callbacks in the background?

On a general note, we have tried to make requestAnimationFrame behave 
like other animations, including CSS animations, CSS transitions, and 
SMIL animations.

In particular, its behavior should probably be similar to 
animation/transition end events and SMIL events.

Is there agreement on that much?

If so, then the real question is whether all those events can be delayed 
indefinitely in background tabs.

> One thing that just occurred to me is that the Page Visibility spec is
> conservative in that implementations must not indicate that a page is
> invisible if it is in fact visible, but that it is allowed to indicate
> that a page is visible if it is not (since it may be difficult to know
> for sure).  It seems like, to be consistent with that, implementations
> would need to be allowed to continue firing requestAnimationFrame
> callbacks for background pages if they wanted.

Indeed.  The visibility state and the throttling are tied together in 
Gecko's case, for what it's worth.

-Boris

Received on Wednesday, 6 July 2011 22:05:35 UTC