[webkit-dev] Page Visibility API

Shishir Agrawal shishir at chromium.org
Tue Mar 8 11:35:09 PST 2011


Hi All,

We would like to implement a Page Visibility API in webkit. The
corresponding bug is at: https://bugs.webkit.org/show_bug.cgi?id=54181 . The
bug has details of the proposal, link to the whatwg discussion as well as a
patch. The proposal is also pasted below for convenience.

Please let me know if you have any questions / concerns.

Thanks
Shishir

<< Proposal details >>


Hi all,

There is currently no good way for a web page to detect that it is
completely invisible to the user (for example, that it is a background tab),
although some imperfect heuristics do exist. In the future, there may be
cases where such detection is even more important, for example in the
prerendering feature that Chromium is currently in the early stages of
experimentation with.

Note that an earlier version of this proposal was sent to the what-wg
mailing list for comment earlier
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-December/029382.html),
and received comments that led to several revisions. The following proposal
introduces only a minor change on top of the result of that discussion
(specifically, renaming document.visibility to document.visibilityState and
document.isVisible to document.visible, in order to encourage developers to
prefer using the simpler boolean property).

Use cases

* A page wants to detect when it is being prerendered so it can behave
appropriately.
* A puzzle game has a timer that keeps track of how long the user has taken
to solve the puzzle.  It wants to pause the timer when the user has hidden
the tab.
* A web app that uses polling to fetch dynamic content can pause polling
when it knows the page is hidden from the user.
* A streaming video site doesn’t want to start the video until the user
actually views the tab for the first time (i.e. video shouldn’t start
automatically if a user opens the tab in the background).
* An in-browser collaborative editing environment wants to update a user’s
status to away when the editing surface is not visible to the user.


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).


document.visibilityState

A read-only property that returns a string, one of the values described in
the next section.  Developers can use the existence of this property to know
that they can rely on the rest of this API, too.

* Values returned by all conforming implementations
    * “visible” : the full-size page content may be at least partially
visible on at least one screen.
    * “hidden” : the full-size page content is not visible to the user at
all.
* Additional values potentially returned by some implementations in some
cases
    * “prerender” : the page is currently being loaded off-screen and might
never be shown to the user.
    * “cache” : the page is currently “frozen” in a cache and not displayed
on screen (e.g. the back-forward cache).
    * “preview” : the page is currently visible only in a lower-resolution
thumbnail.

States in the second set are not guaranteed to be returned in all cases
where they might otherwise appear to apply--it is left to the discretion of
the implementation.

Additional return values may be added to this API in the future.

It is up to the implementation to interpret what these values mean in the
precise context of interface and platform.  As an example, a
current-generation desktop browser might interpret the values the following
way:
“visible” : the tab is focused in its non-minimized window (regardless of
the focus state of the containing window).
“hidden” : the tab is backgrounded within its window, or the containing
window is minimized.


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110308/ffc0d296/attachment.html>


More information about the webkit-dev mailing list