[webkit-dev] Page Visibility API
shishir at chromium.org
Wed Mar 9 10:13:15 PST 2011
Although some use cases are covered by window.onblur, it also fires when a
window looses focus, but may still be visible.
On Tue, Mar 8, 2011 at 12:00 PM, Charles Pritchard <chuck at jumis.com> wrote:
> requestAnimationFrame may provide a method for 'pausing', when following a
> window blur event.
> It was recently added.
> 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>
> 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.
> << 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>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
> * 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.
> * 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
> 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).
> 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
> * Additional values potentially returned by some implementations in some
> * “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
> 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
> “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.
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-dev