Looking at https://developer.mozilla.org/en/docs/Web/HTML/Element/iframe
Wouldn't maybe the addition of new attribute to the iframe be the best way?
**************************
autopause
If present the client can pause any processing related to the
iframe if the iframe is not currently visible. When unpaused a Page
Visibility event will be sent to the iframe as if the whole page had
changed status from invisible to visible.
For visibility events see
https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API
**************************
This basically makes it opt in, it changes nothing about the behavior of
current iframes.
Just an example would be a iframe that can be hidden/unhidden by the
user clicking a button, and if the iframe has the autopause attribute
then it's state is effectively paused. Once the iframe is unpaued a Page
Visibility event is sent and whatever code is running in the frame can
then react to this and and resume, as it never got a event indicating
the page was made non-visible a programmer should be able to
programmatically infer that the iframe was unpaused (it only got the one
event instead of two).
What type of iframes would benefit from this? Some chats, news feeds,
log views, anything that "constantly" updates or works in the
background, but does not need to be updated if not viewable (saves CPU,
bandwidth, and server resources)
And maybe down the road one could see if a similar autopause can be
added to the parent page itself (or not). Maybe a "autopause" would make
sense if added as a attribute to the body (but actually apply to the
whole document including any scripts declared in the head).
Adding a autopause attribute to a iframe is probably the easiest way to
add/deal with this.
If nobody ends up using it, it can easily be dropped again too, so there
is no immediate downside to this that I can currently think of at least.
On 2015-03-31 02:17, Seth Fowler wrote:
I do want to clarify one other thing: we’re definitely not yet at the point of
implementing this in Gecko, especially not in a release version. We think this
functionality is important, and modifying the Page Visibility spec is one way
to make it accessible to the web. It’s probably even the nicest way to make it
accessible to the web, if it’s feasible. But it’s not certain that it’s web
compatible or that everyone agrees this is the best way to go; we’re at the
starting point of the process here.
I’d be interested to hear any comments that others may have!
Thanks,
- Seth
On Mar 30, 2015, at 3:47 PM, Seth Fowler <s...@mozilla.com> wrote:
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.
....
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.
...
- Seth
--
Roger Hågensen, Freelancer, http://skuldwyrm.no/