I think we should modify the Page Visibility spec to let UA’s take actual visibility of iframes into account when deciding if an iframe is hidden.
Right now, the visibility of an iframe is the same as that of the top level browsing context it’s embedded in. Here are the details: http://www.w3.org/TR/page-visibility/ <http://www.w3.org/TR/page-visibility/> This design doesn’t do much for iframes which may be doing significant work, though. The most obvious example is HTML5 ads. These ads may be performing significant work - computation, network IO, rendering, etc. Some or all of that work is often unnecessary when the ad is outside the viewport. Having an API that would allow those ads to throttle back their work when they’re not visible could have significant positive effects on performance and battery life. We could get these benefits through a very simple modification of the Page Visibility spec. We should make the visibility of iframes independent of the top-level browsing context, and instead let UA’s take the actual visibility of the iframes into account. If an iframe has been scrolled out of the viewport, has become occluded, or has otherwise been rendered non-visible, we should regard the iframe as hidden and dispatch a visibilitychange event to let the iframe throttle itself. I think it’s worth noting that requestAnimationFrame could cover some of the rendering-related part of this issue, but it’s frequently the case that iframes are performing a good deal of computation and IO that isn’t tied to requestAnimationFrame. Even for the rendering case, the requestAnimationFrame API doesn’t give iframes any way to detect this kind of transition between a state where fast rendering is important and a state where it’s not useful, so in practice extending the Page Visibility spec in this way will often be useful even for iframes which rely mostly on requestAnimationFrame. I think we should view this change as complementary to the benefits that requestAnimationFrame can give us. If there’s willingness to change the spec, this is a change we’d be interested in making in Gecko in the near term. Sound good? Thanks, - Seth
