RE: making page visibility a property of document instead of top level browsing context

To be clear, Page Visibility Level 2 has not yet been published as a FPWD and is in a very early stage of discussion. Let's not rush changes to our implementations of Page Visibility Level 1, but rather consider carefully what improvements we want to make in Page Visibility Level 2 or another spec.

The working group designed Page Visibility L1 (PVL1) to solve a very specific performance problem around the top level document and browser windowing management. Prior to this API, web developers had no knowledge of whether their web application was even visible to the user due to the state of the browser window or tab in which their web application was running. For example, if a user had ten web applications opened in individual tabs in a single browser window, but the browser window was minimized, all of those applications would be consuming power as if they were all visible to the user. Even if this browser window wasn’t minimized, nine out of ten web applications would be in background tabs still consuming power even though the user could not view them. PVL1 shares this important visibility information with web developers, which wasn’t previously available, to help web developers use system resources more efficiently. PVL1 also covers the case where the web application is prerendered but not viewed by the user, again allowing developers to throttle down activity when the application isn’t visible to the user. This API has helped improve battery life in operating systems like Windows, Android, OS X, and others where this API has been implemented. This API specifically did not attempt to solve any element level visibility problems within the top level document, be it an iframe, Canvas, or other element.

Now that we have solved that larger performance problem, I want to understand how we can also help provide visibility information on elements within the top level document in a compatible and useful way for developers. The current discussion is focused just on display:none iframes, however, there are many other ‘visibility’ scenarios that need to be discussed and other elements that should also be considered. Aside from display:none, a user’s visibility of an iframe or any other element on a page can also be impacted by display:hidden, opacity, z-index, overlapping by other elements, width of the element (e.g., 1x1 px element is in effect hidden), horizontally or vertically scrolled off of the viewport by the user. For the viewport scenario, we still need to determine a definition of what it means for an element to be not in the viewport. Do we use layout positioning? But layout position does not necessarily align with what is rendered to the display. Determining what is rendered on the display isn’t easy. What if a transform has been set then what we think is visible to the user may not be. Before we decide to change the definition of Page Visibility in the Level 2 spec to support display:none iframes, we need to evaluate each of these cases and consider solutions that solve those problems in a compatible way. Whether we change the meaning of existing properties or create new properties in a Page Visibility L2 or Element Visibility spec still needs to be discussed.

On the compatibility front, one of the principles we used in PVL1 was that we never report something is hidden if it’s truly visible to the user, however, we can error on reporting something is visible when it’s truly hidden if we can’t determine if it’s truly hidden. For example, if my browser window is fully obscured by other application windows, it's truly hidden but PVL1 reports it at as being visible. The idea here is that the user should never have to view the 'hidden' web application experience, but we can tolerate some additional power usage in the background if we can't accurately determine if the web application is truly hidden. I don’t see improving where we wrongly reported something as being visible but was truly hidden to the user, but now can correctly report it correctly as hidden, as a compatibility issue. I see that as improving the accuracy of our results. Does anyone have concerns with this view?

Thanks,
Jatinder


-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Sunday, January 26, 2014 6:03 PM
To: Arvind Jain
Cc: Ojan Vafai; Jonas Sicking; public-web-perf@w3.org
Subject: Re: making page visibility a property of document instead of top level browsing context

On 1/25/14 8:24 AM, Arvind Jain wrote:
> Yes it is unfortunate that we are suggesting a non-compatible change.
> Earlier in this thread, we discussed this - I'm pasting that exchange 
> below. Please let us know what you think we should do.

If we think we want to make this change, then what we _should_ do is get UAs to change behavior ASAP, and pray that there is no one depending on the old behavior yet.  The longer the old behavior sticks around, the harder it becomes to change.

Any UAs volunteering to go first?

-Boris

Received on Monday, 27 January 2014 21:41:02 UTC