[webkit-dev] Page Visibility API

Tue Mar 8 12:00:07 PST 2011

requestAnimationFrame may provide a method for 'pausing', when following a window blur event.

It was recently added.

-Charles

On Mar 8, 2011, at 11:35 AM, Shishir Agrawal <shishir at chromium.org> wrote:

> 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.
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110308/6e0eb128/attachment.html>