Re: Proposal for a page visibility API

On Thu, 20 Jan 2011 03:22:29 +0100, Alex Komoroske  
<> wrote:

> Hi all,
> There is currently no good way for a web page to detect that it is
> completely invisible to the user...

We have implemented something like this for our extensions framework,  
where it is common to have messaging between a tb and the background tab  
where the main extension logic runs. It would also make sense for  
applications that might want to communicate with each other client-side,  
rather than having to pass everything through a server (not so relevant to  
the common Google models, but very relevant to applications that  
explicitly don't want to share with a cloud provider).

> Use cases

* An app can provide notifications (using the Web Notification stuff that  
is under developemnt) when it is not visible/focused, but skip them when  
it is to minimise distractions and reduce cognitive load
* An application can (try to) communicate with the currently focused  
application. This is essentially what a whole class of extensions does in  
practice. Enabling it for general HTML would be a step towards making it  
possible to share different functionality extensions. Right now, it would  
rely on out-of-band agreement about how to communicate, but that is  
perfectly feasible in practice. It also introduces a clear requirement for  
a security discussion (see the paper that Art posted recently...).

> With these use-cases in mind, there are a number of requirements.
> Requirements
> * Easy for developers to write scripts that fall back on old behaviors  
> for browsers that do not implement this API
> * Ability to query the document’s current visibility state
> * Events fired when the document transitions between visibility states
> * Ability for browser vendors to add new visibility states in the future
> Proposed API
> document.visible
> Returns true if document.visibilityState’s current value is in the set of
> visibility states considered to be visible (see the next section for
> information on document.visibilityState).  In practice document.visible  
> is merely a convenience property that is well-suited to simple uses.
> In most implementations, only the “visible” state is considered visible--
> although some implementations may consider other values to be visible as
> well (for example, an implementation that makes use of nearly-full-size
> thumbnail previews may consider “preview” to be a visible state).

The idea that a thumbnail, or popup, can mean that more than one document  
is visible is interesting.

In our API we have getFocused() (which mostly does what it says on the  
box, although certain special tabs don't respond to it)

> document.visibilityState
> A read-only property that returns a string

It would make sense to have this relate to the ViewModes stuff that was  
originally developed for widgets, no?

> visibilitychange
> A simple event, fired at the document object immediately after
> document.visibilityState transitions between visibility states.  The  
> event has a property, fromState, that is set to the value of
> document.visibilityState just before it was changed to the current value.
>  Note that visibility has nothing to do with whether the document’s  
> contents have fully loaded or not, which implies that for any given
> visibility transition event, onload may or may not have already fired.

We have tabs.onblur and tabs.onfocus - which is not the same as visibility  
state since it is about more than just rendering, like where input will  
actually go.

Note that our API is currently implemented from a global perspective - you  
can find out what the current tab is, but a tab would have to do that then  
compare to itself, rather than being able to directly query its state. I  
am finding that there are disadvantages to not ahving that information  
readily available.



Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk       Try Opera:

Received on Thursday, 20 January 2011 10:51:58 UTC