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 . 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@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
