Re: Proposal for a page visibility API
On Fri, Jan 21, 2011 at 10:24 AM, Drew Wilson atwil...@google.com wrote: I wanted to point out that many of these use cases are covered adequately by document.focus()/document.blur(), which is what we currently use in Gmail to decide whether to mark the user as away, decide whether to display notifications, etc. In fact, I think the only two use cases that aren't already covered by the focus/blur notifications are: * Page wants to detect prerendering * Web app wants to stop updating when it's not visible. The latter set of use-cases are covered by the requestAnimationFrame API (in various versions, previously discussed on this list), which has particular advantages for those use-cases. So this proposal seems mainly useful for prerendering. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: [Desktop-extensions-team] Proposal for a page visibility API
On Thu, 20 Jan 2011 11:51:17 +0100, Charles McCathieNevile cha...@opera.com wrote: Use cases * An app can provide notifications (using the Web Notification stuff that is under developemnt) when it is not visible/focused, but skip them when it is to minimise distractions and reduce cognitive load * An application can (try to) communicate with the currently focused application. This is essentially what a whole class of extensions does in practice. Enabling it for general HTML would be a step towards making it possible to share different functionality extensions. Right now, it would rely on out-of-band agreement about how to communicate, but that is perfectly feasible in practice. It also introduces a clear requirement for a security discussion (see the paper that Art posted recently...). Also, an app that knows it's invisible can stop, for example, some expensive canvas rendering that no-one will see, making your laptop battery happier. -- Alexey Feldgendler Software Developer, Desktop Team, Opera Software ASA [ICQ: 115226275] http://my.opera.com/feldgendler/
Re: Proposal for a page visibility API
On Thu, Jan 20, 2011 at 12:50 PM, Glenn Maynard gl...@zewt.org wrote: On Thu, Jan 20, 2011 at 2:36 PM, Alex Komoroske komoro...@chromium.orgwrote: If you intend preview to include large but smaller-than-full-size previews, eg. scaled to 50%, I'd recommend avoiding the word thumbnail; I think most people wouldn't consider that a thumbnail. (I could probably come up with a reasonable UI where a preview is at 100%, too...) I agree, although I'm struggling with the precise wording to replace that description with. Do you have any suggestions? I did, too. The main generality behind previews that I came up with is that they're not actually the real, interactive page; they're more like a picture of the page than the page itself (eg. moving the mouse over it won't trip any mouseovers)--but that's far too complicated to get into for a description that should be simple and generalized. How about: “preview” : the page may be at least partially visible, but not in an interactive form (e.g. a lower-resolution thumbnail when switching between tabs). 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. This should also include the old document.visibility value. Agreed, but what should the property of the event be called? fromVisible seems awkward. wasVisible is more natural, but it may be inconsistent to use both from and was in the same event. I'm not sure if there are any precedents to follow... I have a moderate preference for wasVisible given the extreme awkwardness of fromVisible On Thu, Jan 20, 2011 at 6:47 AM, Boris Zbarsky bzbar...@mit.edu wrote: So an iframe that's scrolled out of view could return hidden if the browser wants? That's probably bad: if you're in a hidden iframe, you likely want to know if the document you're in is visible, not to always think you're hidden. I think that's right. I'll add language that makes it clear it's the top-most containing page visibility. If in the future there are valid use cases for an iframe to know when it's hidden within its visible parent or scrolled off screen, we could provide an additional visibility state in the second (optional) set of return values for document.visibilityState that can be used for this case. -- Glenn Maynard
Re: Proposal for a page visibility API
On Wed, Jan 19, 2011 at 9:22 PM, Alex Komoroske komoro...@chromium.orgwrote: 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). Another example of this use case: a browser session is restored with many tabs. As with loading a link in a background tab, video shouldn't start playing. I've lost count of the number of times I've reloaded my browser and had a YouTube video or three start playing (somewhere among my three browser windows and around 60-80 tabs). Note that the Flash videos on http://www.ted.com do load paused if they're loaded in the background, which is very helpful; I can middle-click lots of videos in the video index into background tabs, and then view them one at a time. It should be possible to implement this for HTML5 video. The same applies to anything that plays sound, like games--they shouldn't start immediately when they're in a background tab on load. * Values returned by all conforming implementations * “visible” : the full-size page content may be at least partially visible on at least one screen. More simply, the full-size page content may be at least partially visible. * “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. I think that at least visible and hidden should be explicitly defined as having document.visible true and false, not technically left implementation-defined. Defining prerender and cache as false is probably good too, if their descriptions specifically say off-screen. If you intend preview to include large but smaller-than-full-size previews, eg. scaled to 50%, I'd recommend avoiding the word thumbnail; I think most people wouldn't consider that a thumbnail. (I could probably come up with a reasonable UI where a preview is at 100%, too...) 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. This should also include the old document.visibility value. Thoughts and comments are welcome. I think is very important information to make available to scripts. -- Glenn Maynard
Re: Proposal for a page visibility API
On Thu, 20 Jan 2011 03:22:29 +0100, Alex Komoroske komoro...@chromium.org wrote: Hi all, There is currently no good way for a web page to detect that it is completely invisible to the user... We have implemented something like this for our extensions framework, where it is common to have messaging between a tb and the background tab where the main extension logic runs. It would also make sense for applications that might want to communicate with each other client-side, rather than having to pass everything through a server (not so relevant to the common Google models, but very relevant to applications that explicitly don't want to share with a cloud provider). Use cases * An app can provide notifications (using the Web Notification stuff that is under developemnt) when it is not visible/focused, but skip them when it is to minimise distractions and reduce cognitive load * An application can (try to) communicate with the currently focused application. This is essentially what a whole class of extensions does in practice. Enabling it for general HTML would be a step towards making it possible to share different functionality extensions. Right now, it would rely on out-of-band agreement about how to communicate, but that is perfectly feasible in practice. It also introduces a clear requirement for a security discussion (see the paper that Art posted recently...). 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). The idea that a thumbnail, or popup, can mean that more than one document is visible is interesting. In our API we have getFocused() (which mostly does what it says on the box, although certain special tabs don't respond to it) document.visibilityState A read-only property that returns a string It would make sense to have this relate to the ViewModes stuff that was originally developed for widgets, no? 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. We have tabs.onblur and tabs.onfocus - which is not the same as visibility state since it is about more than just rendering, like where input will actually go. Note that our API is currently implemented from a global perspective - you can find out what the current tab is, but a tab would have to do that then compare to itself, rather than being able to directly query its state. I am finding that there are disadvantages to not ahving that information readily available. cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: Proposal for a page visibility API
On 1/20/11 5:02 AM, Glenn Maynard wrote: * Values returned by all conforming implementations * “visible” : the full-size page content may be at least partially visible on at least one screen. More simply, the full-size page content may be at least partially visible. * “hidden” : the full-size page content is not visible to the user at all. So an iframe that's scrolled out of view could return hidden if the browser wants? Why is full-size in there? If I have a background set to -moz-element for some element, but am scaling it down to half-size or whatnot, why should it not be considered visible? Note that this is not the same as preview; the page is just being shown at some size that's clearly not a thumbnail but not full-size. Heck, if the user zooms the page is no longer shown full-size... -Boris
Re: Proposal for a page visibility API
On Thu, Jan 20, 2011 at 2:02 AM, Glenn Maynard gl...@zewt.org wrote: On Wed, Jan 19, 2011 at 9:22 PM, Alex Komoroske komoro...@chromium.orgwrote: 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). Another example of this use case: a browser session is restored with many tabs. As with loading a link in a background tab, video shouldn't start playing. I've lost count of the number of times I've reloaded my browser and had a YouTube video or three start playing (somewhere among my three browser windows and around 60-80 tabs). Note that the Flash videos on http://www.ted.com do load paused if they're loaded in the background, which is very helpful; I can middle-click lots of videos in the video index into background tabs, and then view them one at a time. It should be possible to implement this for HTML5 video. The same applies to anything that plays sound, like games--they shouldn't start immediately when they're in a background tab on load. Agreed, these are common and valuable use cases. * Values returned by all conforming implementations * “visible” : the full-size page content may be at least partially visible on at least one screen. More simply, the full-size page content may be at least partially visible. Agreed. Changed. * “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. I think that at least visible and hidden should be explicitly defined as having document.visible true and false, not technically left implementation-defined. Defining prerender and cache as false is probably good too, if their descriptions specifically say off-screen. Agreed, and changed. If you intend preview to include large but smaller-than-full-size previews, eg. scaled to 50%, I'd recommend avoiding the word thumbnail; I think most people wouldn't consider that a thumbnail. (I could probably come up with a reasonable UI where a preview is at 100%, too...) I agree, although I'm struggling with the precise wording to replace that description with. Do you have any suggestions? 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. This should also include the old document.visibility value. Agreed, but what should the property of the event be called? fromVisible seems awkward. Thoughts and comments are welcome. I think is very important information to make available to scripts. Just to make my agreement complete, I'll point out that I agree about this, as well. :-) -- Glenn Maynard
Re: Proposal for a page visibility API
On Thu, Jan 20, 2011 at 2:51 AM, Charles McCathieNevile cha...@opera.comwrote: On Thu, 20 Jan 2011 03:22:29 +0100, Alex Komoroske komoro...@chromium.org wrote: Use cases * An app can provide notifications (using the Web Notification stuff that is under developemnt) when it is not visible/focused, but skip them when it is to minimise distractions and reduce cognitive load Great use case, I'll add this to the list. * An application can (try to) communicate with the currently focused application. This is essentially what a whole class of extensions does in practice. Enabling it for general HTML would be a step towards making it possible to share different functionality extensions. Right now, it would rely on out-of-band agreement about how to communicate, but that is perfectly feasible in practice. It also introduces a clear requirement for a security discussion (see the paper that Art posted recently...). Although I think this is an interesting and valid use case (and one, as you point out, that has many examples in practice today), I think it has the potential to complicate this proposal, especially regarding security (again, as you note). Is there a way to design this API in a way that makes the additional functionality fit in better in some future proposal? The idea that a thumbnail, or popup, can mean that more than one document is visible is interesting. Agreed. The bulk of the discussion on the what-wg list centered around what, precisely, it meant to be visible. We identified a number of interesting cases, like the preview features that some browsers implement today. Other complexities include multiple screens and windows that are partially or completely obscured by other windows. That led to the current wording of this proposal, which is deliberately somewhat vague and interface-concept agnostic, and only provides a strong guarantee that, if the API says you're hidden, you are definitely hidden. (However, note that it is possible for the API to report that you're visible when in practice you aren't, e.g. when your window is completely obscured by another window.) In our API we have getFocused() (which mostly does what it says on the box, although certain special tabs don't respond to it) document.visibilityState A read-only property that returns a string It would make sense to have this relate to the ViewModes stuff that was originally developed for widgets, no? Based on my reading of the view-modes in the widgets spec, I don't think they relate particularly closely. View-mode seems to be a request from the app for a specific type of display, whereas this API proposes a way for a page to query its visibility but not request a change in visibility. Also note that the specific UI concepts of fullscreen, windowed, etc are deliberately avoided by this API for the reasons that I referenced above from the what-wg thread.
Re: Proposal for a page visibility API
For clarity, I've included the current draft of the proposal below, which incorporates the feedback from this thread. 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. 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. * A web-based chat application wants to show the user notifications via the Web Notification API when a message is received, but only when the page 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 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. The “visible” state is considered to be visible in all implementations. “hidden”, “prerender”, and “cache” are considered to be hidden in all implementations. The visibility of additional values, including “preview”, are up to the discretion of the implementation (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 page content may be at least partially visible. * “hidden” : the 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 version. Visibility states considered to be visible, for the purposes of document.visible, include “visible”. 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 two properties, fromState and fromVisible, that are set to the value of document.visibilityState and document.visible, respectively, just before they were changed to the current value. The eventNote 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.
