RE: [Page Visibility 2] Request for Comments

Hi Boris:

Test here http://www.w3.org/2014/10/pv2/iframe-hidden.html, right, it is a display:none iframe. I quite agree with that we shall not fire in this case (follow PV2), to benefit power and performance. 
As my understanding, we have two category cases. One is animation related, e.g. rAF, or the apps animated in iframe via other method. In this case I think we can smoothly migrated to PV2, as we all agree that when they access iframe .hidden, they expect the frame visibility(PV2) rather than top browsing context visibility(PV1), in other words, frame visibility should be the one dominate if animate or not. 
Another category is that non-animation related, e.g. the vibration, we are not sure if they are widely used it within a display:none(or other hidden) iframe, not sure if they all expect to be tied to top browsing context. So, I think it is worthy to try the change first to see if we can go through.
Or, if there is strong use case that we need to tie iframe .hidden to top browsing context. I would like to propose keep PV1 .hidden, and add .frameHidden in PV2.
Any idea?

Thanks
Pan

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@mit.edu] 
Sent: Thursday, October 30, 2014 9:36 PM
To: Michael Blain
Cc: public-web-perf@w3.org
Subject: Re: [Page Visibility 2] Request for Comments

On 10/31/14, 12:18 AM, Michael Blain wrote:
> When a frame was off screen, it didn't fire rAFs.

Link to the testcase, please?  I'm aware of no such behavior in Gecko. 
The only times we flat out don't fire rAF are when the document is in a display:none subtree or when the document is .hidden and all hidden documents have been hidden for at least 10 minutes.  In all other cases we will fire it (though in some situations at a greatly reduced rate).

In particular, we do not follow the "hidden == no firing at all" bits of the rAF spec, pending our concerns about behavior aligning between rAF, transition/animation events, and SMIL events being addressed.

> I think if Mozilla could just set the .hidden property based on 
> whatever mechanism is controlling suppressing those rAFs, you guys 
> would be good to go.

Again, .hidden affects APIs other than rAF.

> That was why the attendees thought it would be OK to try and make the 
> change first, and see if it brakes things later.

I look forward to the attendees shipping browsers with the changes they think are web-compatible.  Then we can evaluate.

> The reason the spec steered clear of using MUST in terms of setting 
> .hidden = true is because there are many situations and edge-cases 
> where the browser might not know (without extra effort) for CERTAIN 
> that something is visible.

Yes, but if .hidden controls whether other APIs actually work or not, then the only way to get basic interop is to have browsers actually agree on when it's set.

So you have two options, in my opinion: either divorce .hidden from other APIs, and have it be a best-effort thing, or actually define its behavior if other APIs are supposed to depend on it.

> I think that part could be up for debate. if rAF isn't the only API 
> affected

It's certainly not.  This has been pointed out several times now.

-Boris

Received on Friday, 31 October 2014 19:31:36 UTC