[RequestAnimationFrame] suspending callbacks in background pages

Today in the call we brought up one as yet unresolved aspect of the
requestAnimationFrame processing model, whether callbacks should be
called at all in pages that are in the background.  Last I checked, we
(Gecko) have an exponential backoff in the callback invocation rate for
background pages, while WebKit and the recently released IE
implementation do not invoke the callbacks at all.

One of the arguments for invoking the callbacks, but slowly, was that
pages may be expecting to be notified of the end of the animation at
some point (even if it is not right on time) so that other work could be
performed.  As an example, you could imagine an interstitial ad that
uses requestAnimationFrame to perform some animation, at the end of
which the page is navigated to the article the user actually wanted to
see.  If callbacks aren’t invoked at all in the background tab, and the
user does open this page in the background, then it won’t be until they
switch to the tab (potentially long after the animation would have
finished) before the navigation happens.

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?

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.

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Wednesday, 6 July 2011 21:57:12 UTC