Re: [whatwg] Modify the Page Visibility spec to let UA's take into account whether iframes are visible on the screen

"autopause" looks promising, but I want to ask for more: also add an 
"autounload" attribute to allow UAs to unload specific iframes when they 
are invisible.

I ask for this because I'm a contributor of pdf2htmlEX ( 
https://github.com/coolwanglu/pdf2htmlEX ).
Currently pdf2htmlEX can convert each PDF page to one SVG image and 
embed it in the main HTML via <embed>s （almost equivalent to <iframe> 
here).
However, if the PDF file contains many pages, the memory consumption of 
<embed>s becomes unacceptable, although most of them are out of the 
viewport.
Because UAs are not allowed to automatically unload invisible nested 
browsing context, we have to do this in JS (by removing/adding <embed>s 
from/to the tree). This is complicated and doesn't work if JS is 
disabled. If "autounload" were supported, things would be much simpler.

Also I think in some use cases of "autopause", "autounload" is even more 
suitable becaue it not only save CPU and network, but also save memory,
which are equally important to mobile devices.

在 2015年03月31日 14:18, Roger Hågensen 写道:
> 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 <seth@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
>

Received on Tuesday, 31 March 2015 08:17:02 UTC