Re: [webkit-dev] Page Visibility API
Although some use cases are covered by window.onblur, it also fires when a window looses focus, but may still be visible. Thanks Shishir On Tue, Mar 8, 2011 at 12:00 PM, Charles Pritchard ch...@jumis.com wrote: 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 shis...@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. 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.htmlhttp://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
[webkit-dev] Page Visibility API
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
