Re: [RequestAnimationFrame] suspending callbacks in background pages

On Wed, Jul 6, 2011 at 3:04 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> 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.


This is a really interesting question.  Currently, in Safari on iOS
animations and transitions are suspended, including the related events, in
background tabs.  When the user switches back to the tab the
animation/transition resumes from the state it was in.  I'm not convinced
this behavior is the best in all cases, but it is an interesting idea.  I
think we should try to resolve what the expected behavior here is on
public-fx.

That said, my mental model for imperative animations is that the state
transitions (start/end/iteration) and the individual 'ticks' used to update
the animated values.  It doesn't make sense to 'tick' an animation and
update the interpolated values in a background tab.  I think the key
questions then are:
1.) Are authors depending on the 'tick' to trigger their state transition
logic, and if so
2.) Does the lack of the state transition logic trigger in background tabs
break pages?


>
>  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.
>

Same for Chrome, at least for now.  In cases where it's ambiguous or
difficult to determine whether a tab is visible or not we'll always err on
the side of thinking tabs are visible.

- James



>
> -Boris
>
>
>