On Thu, 20 Jan 2011 03:22:29 +0100, Alex Komoroske
<komoro...@chromium.org> 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.
cheers
Chaals
--
Charles McCathieNevile Opera Software, Standards Group
je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals Try Opera: http://www.opera.com
