Re: [whatwg] Proposal for a tab visibility API
Back in December there was a discussion about a tab visibility API. I haven't added this feature to the HTML specification at this time, for a couple of reasons: first, it seems like something we'd really want to have implementation experience before deciding on a specific API, and second, it seems like something that belongs more in the CSSOM API spec than in the primarily media-independent HTML spec. I have saved all the feedback on the topic in case anyone is interested in working on a specification for this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for a tab visibility API
On Thu, Apr 28, 2011 at 12:40 PM, Ian Hickson i...@hixie.ch wrote: Back in December there was a discussion about a tab visibility API. I haven't added this feature to the HTML specification at this time, for a couple of reasons: first, it seems like something we'd really want to have implementation experience before deciding on a specific API, and second, it seems like something that belongs more in the CSSOM API spec than in the primarily media-independent HTML spec. I have saved all the feedback on the topic in case anyone is interested in working on a specification for this. For what it's worth the Web Performance working group has added this to its charter and has started work on this API: http://www.w3.org/2011/04/webperf.html. - James -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal for a tab visibility API
James Robinson jam...@google.com, 2011-04-28 13:08 -0700: On Thu, Apr 28, 2011 at 12:40 PM, Ian Hickson i...@hixie.ch wrote: Back in December there was a discussion about a tab visibility API. I haven't added this feature to the HTML specification at this time, for a couple of reasons: first, it seems like something we'd really want to have implementation experience before deciding on a specific API, and second, it seems like something that belongs more in the CSSOM API spec than in the primarily media-independent HTML spec. I have saved all the feedback on the topic in case anyone is interested in working on a specification for this. For what it's worth the Web Performance working group has added this to its charter and has started work on this API: http://www.w3.org/2011/04/webperf.html. There's a draft spec here: http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html So the feedback should probably either go the public-web-p...@w3.org mailing list, with [PageVisibility] in the subject - http://lists.w3.org/Archives/Public/public-web-perf/ ...or directly to the editors (Jatinder Mann from Microsoft and Arvind Jain from Google). --Mike -- Michael[tm] Smith http://people.w3.org/mike
Re: [whatwg] Proposal for a tab visibility API
On Tue, Jan 4, 2011 at 6:50 PM, Glenn Maynard gl...@zewt.org wrote: * “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. I'd even say * hidden: the full-size page content is guaranteed not to be visible to the user at all. * visible: the full-size page content may or may not be visible to the user. Browsers just can't reasonably account for things like the tab being on a second monitor that's turned off or who knows what. You can only guarantee that it's hidden, not that it's visible.
Re: [whatwg] Proposal for a tab visibility API
Hi all, Thanks again for your comments and feedback. It's been a couple of weeks since the last activity on this thread, and I wanted to take the opportunity to do a very high-level summary of the discussion so far and put forward an updated version of the proposal (which I've included at the end of this e-mail). My high-level summary: Although there is *high *level agreement about the need for a similar type of API, there are a number of concerns: 1) *Additional potential for abuse*. My response to this was Although there is some additional opportunity for abuse, I think that it is not particularly large, possible to defend against if necessary, and outweighed by the advantages such an API would provide to legitimate web developers. I'd be interested if those who originally raised this concern agree with this assessment. 2) *Not the right tool for the use cases*. Various other proposals, including an ability to set a timer that only fires when a page is visible or a way to semantically define what visibility specific types of content require, have been proposed to address the provided use cases. So far those solutions are not concretely defined. 3) *Too specific about tab/window/visibility*. I've attempted to update the proposal (pasted below) to be more clear about the specific semantics and how they might differ on different platforms. I'd appreciate your comments. *Updated API proposal* * * document.visibility 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 is 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. document.isVisible A simple convenience read-only property that returns a boolean. Returns true if document.visibility’s current value is in the set of visibility states considered to be visible. 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 regular use of nearly-full-size thumbnail previews may consider “preview” to be a visible state). visibilitychange A simple event, fired at the document object immediately after document.visibility transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibility 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. On Mon, Dec 20, 2010 at 3:44 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/20/10 5:16 PM, Alex Komoroske wrote: But I think overall the discussion about precisely what a tab means is not central to the core proposal. Is that reasonable? Yep. -Boris
Re: [whatwg] Proposal for a tab visibility API
On Tue, Jan 4, 2011 at 3:50 PM, Glenn Maynard gl...@zewt.org wrote: The earlier condition that I think you mentioned seemed reasonable: never say the page is hidden when it's not, eg. no false positives. It's more harmful to tell a visible page that it's invisible, than to tell an invisible page that it's visible: * “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. This gives implementations some latitude to decide whether a condition should be treated as hidden, and doesn't require figuring out precisely whether a window is visible in every case. Great point, Glenn. I agree completely. --Alex
Re: [whatwg] Proposal for a tab visibility API
Hi Bjartur, Thanks for your comments. I've replied inline. On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On Wed, 15 Dec 2010 19:27:51 -, Alex Komoroske komoro...@chromium.org wrote: Regarding the fact that background tabs aren't necessarily invisible: - On December 8, Boris Zbarsky wrote: There is no such guarantee for background tabs. For example, browsers may show tab previews in various contexts (Panorama in Firefox 4, e.g.). - The point of the API, as proposed, is that page scripts will know when their content is guaranteed to be invisible to the user--that is, the API will not provide a false positive about invisibility. However, the API may provide false negatives about invisibility, for reasons many others on this thread have been pointed out (including different windowing systems, multiple monitors, partial transparency, etc.). The easiest way to achieve this guarantee is to only consider a tab hidden when it is a background tab within* *a window. The window itself, of course, may be on a little-noticed second monitor, partially obscured, etc. I don´t see how that information is useful. Now, you have to define 'window' and 'tab' differently and define a background state of the latter. Do multiple non-backgrounded (attached) tabs in a window need special treatment? If you use the term 'tab' anywhere it _will_ be confused with the UI metaphor, causing confusion with the approach to hierarchical window management. I don't understand what the term 'tab' means to you. To me a tab is a window. I'm not sure that I understand the point of confusion. When I say 'tab', I mean the current UI construct implemented in Firefox, Safari, Chrome, Opera, Internet Explorer, and others. Each window can have one or more tabs, and in curent implementations (with very few exceptions), each window can only have a single visible tab. But as you point out, there are still some edge cases where even a background tab is visible. In this specific example, I think the right answer would be to have an additional visibility value of preview, which, for the purposes of the isVisible property, would be considered a hidden state. There are some cases where a tab would consider a tab preview to be hidden (like the puzzle timer use case) and some cases where it would be considered visible (like the video playing use case). This would allow web developers to decide for themselves how they wanted to respond to that case. Or, one could mark them up semantically. A video player depends on visibility and audibility and an UA should thus not play video unless it fulfill said requirements. There is also the case of an optional linked soundtrack, which won´t prevent visual playback. In case of an interactive game such as a puzzle, it shouldn't even execute while not focused. IMHO, programs should be stalled (think SIGTTOU) while dynamic requirements can't be fulfilled. In theory, we'd just use blocking operations, but they've been deemed to hard for JavaScript. Regarding the additional abuse potential: Implementations of my counterproposal don't even notify scripts about 'tab' visibility changes, and additionally suspend unimportant scripts, rendering current focus-stealing methods useless. I'm not sure that I have seen your counterproposal. Based on your comments in this thread, I presume that it includes an ability for pages to declare what capabilities they require (e.g. an animation requires that it be visible) and then the browser automatically pauses scripts when those required conditions are not met. Is that a proper understanding of your counterproposal? Is there a more comprehensive/detailed version of the proposal that I could read and comment on? Arguably, it could still be useful to throw an event upon suspension. alert could potentially be removed from window prior to launching the event and the scripts given a timeout, before they get suspended forcibly. I don't know the inner workings of JavaScript implementations to realize whether this could be circumvented by cloning new instances of alert, or whether implementations could simply disable access to potentially harmful methods at an higher level. Regarding the video player use case from the initial proposal: - On December 8th, Maciej Stachowiak wrote: This use case can be handled without help from the page. In Safari, video (whether through media elements or plugins) won't start playing when a user opens a tab in the background, until the user switches to that tab. - Although what you describe satisfies the specific use case, it doesn't address the more general use case of animations (either explicit via javascript or via CSS Animations) or content that is not a plugin/video file. I argue that there are two potentially viable solutions: Implementations exploiting more methods á la Safari,
Re: [whatwg] Proposal for a tab visibility API
On 12/20/10 10:21 AM, Alex Komoroske wrote: I'm not sure that I understand the point of confusion. When I say 'tab', I mean the current UI construct implemented in Firefox, Safari, Chrome, Opera, Internet Explorer, and others. I think the point of confusion is that you think this UI construct is an important fundamental, whereas others thing it's not. Each window can have one or more tabs, and in curent implementations (with very few exceptions), each window can only have a single visible tab. As you note, there are exceptions. What makes you think that two years from now the now-common case won't be the exception? It would be preferable to define whatever visibility API is defined without reference to tabs; they're a possibly-transient implementation detail. For example, Firefox on mobile has different rendering areas, etc, but they're not surfaced as tabs to the user; the UI looks and acts totally different, last I checked (and is implemented quite differently, iirc). -Boris
Re: [whatwg] Proposal for a tab visibility API
On 12/20/10, Alex Komoroske komoro...@chromium.org wrote: Thanks for your comments. I've replied inline. On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On Wed, 15 Dec 2010 19:27:51 -, Alex Komoroske komoro...@chromium.org wrote: Regarding the fact that background tabs aren't necessarily invisible: - On December 8, Boris Zbarsky wrote: There is no such guarantee for background tabs. For example, browsers may show tab previews in various contexts (Panorama in Firefox 4, e.g.). - The point of the API, as proposed, is that page scripts will know when their content is guaranteed to be invisible to the user--that is, the API will not provide a false positive about invisibility. However, the API may provide false negatives about invisibility, for reasons many others on this thread have been pointed out (including different windowing systems, multiple monitors, partial transparency, etc.). The easiest way to achieve this guarantee is to only consider a tab hidden when it is a background tab within* *a window. The window itself, of course, may be on a little-noticed second monitor, partially obscured, etc. The obvious way to achieve this is to only consider a tab/window hidden when it's not on-screen, and consider it visible when it's on-screen. What good is being the current tab when the window is off-screen? I don´t see how that information is useful. Now, you have to define 'window' and 'tab' differently and define a background state of the latter. Do multiple non-backgrounded (attached) tabs in a window need special treatment? If you use the term 'tab' anywhere it _will_ be confused with the UI metaphor, causing confusion with the approach to hierarchical window management. I don't understand what the term 'tab' means to you. To me a tab is a window. I'm not sure that I understand the point of confusion. When I say 'tab', I mean the current UI construct implemented in Firefox, Safari, Chrome, Opera, Internet Explorer, and others. Each window can have one or more tabs, and in curent implementations (with very few exceptions), each window can only have a single visible tab. In context of many of the less-widely used browsers the word 'tab' is never used. Each top-level browsing context has an associated window, which may be grouped with other windows and that group may be represented as a tab strip, wherefrom windows may be selected. They may also be tiled, and a tab strip which allows multiple windows to be selected (tabbed desktops), causing them to tile. How does your proposal work wrt tagged windows (as used in wmii, dwm)? I don't understand an UI construct used by WMs is of any interest to applications. AFAIK, X11 only notifies clients about changing visibility, and by extension, partial overlaps. Why would apps rather know whether they're selected in a tab strip (creating an unnecessary requirement for tab strips) than whether they're visible? With the aforementioned WMs (wmii, dwm) windows may be in multiple groups (tags). In wmii, windows are managed hierarchically. This isn't of any concern to anyone but the user. Applications shouldn't care at all. They're given a resizing window of variable visibility to draw on; tabs don't matter. I'm not sure that I have seen your counterproposal. Based on your comments in this thread, I presume that it includes an ability for pages to declare what capabilities they require (e.g. an animation requires that it be visible) and then the browser automatically pauses scripts when those required conditions are not met. Is that a proper understanding of your counterproposal? Is there a more comprehensive/detailed version of the proposal that I could read and comment on? Yes, your understanding is correct, and no, there is none. On December 8th, Maciej Stachowiak wrote: This use case can be handled without help from the page. In Safari, video (whether through media elements or plugins) won't start playing when a user opens a tab in the background, until the user switches to that tab. - Although what you describe satisfies the specific use case, it doesn't address the more general use case of animations (either explicit via javascript or via CSS Animations) or content that is not a plugin/video file. Modularity is good. I argue that there are two potentially viable solutions: Implementations exploiting more methods á la Safari, stopping animations or apps declaring dependencies on various things like visibility and audibility. There are previous proposals regarding throwing CSS media events upon change, which could potentially be integrated with this. The whole things smells of over-engineering. A resource of MIME media type audio obviously can't be rendered without audibility, image resources sans (2D) visibility nor model resources sans 3D visibility. Text resources can be rendered both visually and aurally, and models
Re: [whatwg] Proposal for a tab visibility API
Ah, yes, thank you Boris, I think I understand now. Note that the actual proposal doesn't depend on the existence of a UI construct called tabs that operate like they do on desktop browsers today. I think the better way to think about it is, if the content of the page is partially visible on *any *screen then it should be considered visible. If it's not visible at all, then it can be considered hidden. This will differ on different browsers and different platforms. I used the word tab only for help in explaining the proposal because today the majority of shipping browsers have a consistent notion of tabs. I agree with you that new UI constructs (and platforms, especially mobile) will change what a tab means. But I think overall the discussion about precisely what a tab means is not central to the core proposal. Is that reasonable? --Alex On Mon, Dec 20, 2010 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 12/20/10 10:21 AM, Alex Komoroske wrote: I'm not sure that I understand the point of confusion. When I say 'tab', I mean the current UI construct implemented in Firefox, Safari, Chrome, Opera, Internet Explorer, and others. I think the point of confusion is that you think this UI construct is an important fundamental, whereas others thing it's not. Each window can have one or more tabs, and in curent implementations (with very few exceptions), each window can only have a single visible tab. As you note, there are exceptions. What makes you think that two years from now the now-common case won't be the exception? It would be preferable to define whatever visibility API is defined without reference to tabs; they're a possibly-transient implementation detail. For example, Firefox on mobile has different rendering areas, etc, but they're not surfaced as tabs to the user; the UI looks and acts totally different, last I checked (and is implemented quite differently, iirc). -Boris
Re: [whatwg] Proposal for a tab visibility API
Hi Bjartur, Thanks for your comments. My responses are inline. On Mon, Dec 20, 2010 at 8:56 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On 12/20/10, Alex Komoroske komoro...@chromium.org wrote: Thanks for your comments. I've replied inline. On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius svartma...@gmail.comwrote: On Wed, 15 Dec 2010 19:27:51 -, Alex Komoroske komoro...@chromium.org wrote: Regarding the fact that background tabs aren't necessarily invisible: - On December 8, Boris Zbarsky wrote: There is no such guarantee for background tabs. For example, browsers may show tab previews in various contexts (Panorama in Firefox 4, e.g.). - The point of the API, as proposed, is that page scripts will know when their content is guaranteed to be invisible to the user--that is, the API will not provide a false positive about invisibility. However, the API may provide false negatives about invisibility, for reasons many others on this thread have been pointed out (including different windowing systems, multiple monitors, partial transparency, etc.). The easiest way to achieve this guarantee is to only consider a tab hidden when it is a background tab within* *a window. The window itself, of course, may be on a little-noticed second monitor, partially obscured, etc. The obvious way to achieve this is to only consider a tab/window hidden when it's not on-screen, and consider it visible when it's on-screen. What good is being the current tab when the window is off-screen? I don´t see how that information is useful. Now, you have to define 'window' and 'tab' differently and define a background state of the latter. Do multiple non-backgrounded (attached) tabs in a window need special treatment? If you use the term 'tab' anywhere it _will_ be confused with the UI metaphor, causing confusion with the approach to hierarchical window management. I don't understand what the term 'tab' means to you. To me a tab is a window. I'm not sure that I understand the point of confusion. When I say 'tab', I mean the current UI construct implemented in Firefox, Safari, Chrome, Opera, Internet Explorer, and others. Each window can have one or more tabs, and in curent implementations (with very few exceptions), each window can only have a single visible tab. In context of many of the less-widely used browsers the word 'tab' is never used. Each top-level browsing context has an associated window, which may be grouped with other windows and that group may be represented as a tab strip, wherefrom windows may be selected. They may also be tiled, and a tab strip which allows multiple windows to be selected (tabbed desktops), causing them to tile. How does your proposal work wrt tagged windows (as used in wmii, dwm)? I don't understand an UI construct used by WMs is of any interest to applications. AFAIK, X11 only notifies clients about changing visibility, and by extension, partial overlaps. Why would apps rather know whether they're selected in a tab strip (creating an unnecessary requirement for tab strips) than whether they're visible? With the aforementioned WMs (wmii, dwm) windows may be in multiple groups (tags). In wmii, windows are managed hierarchically. This isn't of any concern to anyone but the user. Applications shouldn't care at all. They're given a resizing window of variable visibility to draw on; tabs don't matter. Thanks for the clarification. I attempted to address this in the e-mail I just sent in response to Boris. (In a nutshell: I agree with you about tabs not being a central UI concept, but I think that the concept of tab is not core to the proposal.) Let me know if that e-mail doesn't address these concerns. I'm not sure that I have seen your counterproposal. Based on your comments in this thread, I presume that it includes an ability for pages to declare what capabilities they require (e.g. an animation requires that it be visible) and then the browser automatically pauses scripts when those required conditions are not met. Is that a proper understanding of your counterproposal? Is there a more comprehensive/detailed version of the proposal that I could read and comment on? Yes, your understanding is correct, and no, there is none. On December 8th, Maciej Stachowiak wrote: This use case can be handled without help from the page. In Safari, video (whether through media elements or plugins) won't start playing when a user opens a tab in the background, until the user switches to that tab. - Although what you describe satisfies the specific use case, it doesn't address the more general use case of animations (either explicit via javascript or via CSS Animations) or content that is not a plugin/video file. Modularity is good. I argue that there are two potentially
Re: [whatwg] Proposal for a tab visibility API
On 12/20/10 5:16 PM, Alex Komoroske wrote: But I think overall the discussion about precisely what a tab means is not central to the core proposal. Is that reasonable? Yep. -Boris
Re: [whatwg] Proposal for a tab visibility API
On Wed, 15 Dec 2010 19:27:51 -, Alex Komoroske komoro...@chromium.org wrote: Regarding the fact that background tabs aren't necessarily invisible: - On December 8, Boris Zbarsky wrote: There is no such guarantee for background tabs. For example, browsers may show tab previews in various contexts (Panorama in Firefox 4, e.g.). - The point of the API, as proposed, is that page scripts will know when their content is guaranteed to be invisible to the user--that is, the API will not provide a false positive about invisibility. However, the API may provide false negatives about invisibility, for reasons many others on this thread have been pointed out (including different windowing systems, multiple monitors, partial transparency, etc.). The easiest way to achieve this guarantee is to only consider a tab hidden when it is a background tab within* *a window. The window itself, of course, may be on a little-noticed second monitor, partially obscured, etc. I don´t see how that information is useful. Now, you have to define 'window' and 'tab' differently and define a background state of the latter. Do multiple non-backgrounded (attached) tabs in a window need special treatment? If you use the term 'tab' anywhere it _will_ be confused with the UI metaphor, causing confusion with the approach to hierarchical window management. I don't understand what the term 'tab' means to you. To me a tab is a window. But as you point out, there are still some edge cases where even a background tab is visible. In this specific example, I think the right answer would be to have an additional visibility value of preview, which, for the purposes of the isVisible property, would be considered a hidden state. There are some cases where a tab would consider a tab preview to be hidden (like the puzzle timer use case) and some cases where it would be considered visible (like the video playing use case). This would allow web developers to decide for themselves how they wanted to respond to that case. Or, one could mark them up semantically. A video player depends on visibility and audibility and an UA should thus not play video unless it fulfill said requirements. There is also the case of an optional linked soundtrack, which won´t prevent visual playback. In case of an interactive game such as a puzzle, it shouldn't even execute while not focused. IMHO, programs should be stalled (think SIGTTOU) while dynamic requirements can't be fulfilled. In theory, we'd just use blocking operations, but they've been deemed to hard for JavaScript. Regarding the additional abuse potential: Implementations of my counterproposal don't even notify scripts about 'tab' visibility changes, and additionally suspend unimportant scripts, rendering current focus-stealing methods useless. Arguably, it could still be useful to throw an event upon suspension. alert could potentially be removed from window prior to launching the event and the scripts given a timeout, before they get suspended forcibly. I don't know the inner workings of JavaScript implementations to realize whether this could be circumvented by cloning new instances of alert, or whether implementations could simply disable access to potentially harmful methods at an higher level. Regarding the video player use case from the initial proposal: - On December 8th, Maciej Stachowiak wrote: This use case can be handled without help from the page. In Safari, video (whether through media elements or plugins) won't start playing when a user opens a tab in the background, until the user switches to that tab. - Although what you describe satisfies the specific use case, it doesn't address the more general use case of animations (either explicit via javascript or via CSS Animations) or content that is not a plugin/video file. I argue that there are two potentially viable solutions: Implementations exploiting more methods á la Safari, stopping animations or apps declaring dependencies on various things like visibility and audibility. There are previous proposals regarding throwing CSS media events upon change, which could potentially be integrated with this. The whole things smells of over-engineering. A resource of MIME media type audio obviously can't be rendered without audibility, image resources sans (2D) visibility nor model resources sans 3D visibility. Text resources can be rendered both visually and aurally, and models can also be rendered to 2D displays, as long they're interactive (they're redrawable and user input is accessible). Regarding solving the use cases that cannot be addressed currently: -- On December 8th, Maciej Stachowiak wrote: That leaves the following use cases: * 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. The counter is paused while the script's suspended,
Re: [whatwg] Proposal for a tab visibility API
(Subscribed recently; sorry for breaking threading.) On Wed, Dec 8, 2010 at 2:57 PM, Boris Zbarsky bzbar...@mit.edu wrote: 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. In practice, at least in FF and Chrome you can already do this: alert() from window.onblur. I've never seen that in the wild, though that may be ABP blocking scripts that do it. Making those dialogs modal to the tab, as someone mentioned, seems like a solid fix for this and most other problems with those dialogs. So far the only browser I've seen that does this well is Opera. Hopefully, eventually all modal interactions from a tab--login prompts, file open dialogs, etc., will be modal to the tab; a tab should never be able to block the whole window, just as a native application should not be able to block the whole windowing system. It's always frustrating to resume a browser session and have to respond to several authentication prompts before I can use other, unrelated tabs. (Cute FF bug: alerting from onblur brings the tab back into focus, *after* it's closed. Zombie tab! Seems to be fixed in 4.) I think giving pages information that encourages them to pause unnecessary scripts is a good thing; it's hard to complain about background pages wasting resources with scripts when they're not given the information they need to not do so. This seems like a logical extension of the window.onblur/onfocus extensions, which usually aren't enough information. On Wed, 15 Dec 2010 19:27:51 -, Alex Komoroske komoro...@chromium.org wrote: There are some cases where a tab would consider a tab preview to be hidden (like the puzzle timer use case) and some cases where it would be considered visible (like the video playing use case). This would allow web developers to decide for themselves how they wanted to respond to that case. This would mean sending events to every window when previews are displayed, right? That sounds like a performance pit--open a preview display (which should be very quick) and windows with previews-considered-visible behavior all start working at the same time. -- Glenn Maynard
Re: [whatwg] Proposal for a tab visibility API
Hi,
Maybe we can disallow the visibilitychange event to produce any dialogs
or anything else that could give focus?
window.onvisibilitychange = function(e) {
setTimeout(function() {
alert(Worked around!);
}, 0);
};
Or would browsers be able to track that the code was initially
triggered from visibilitychange? (including when programmatically
creating and dispatching another DOM events, instead of or in addition
to the setTimeout?)
You don't have to track where call was coming from:
1. you just don't let the alert take the focus in windows that are not
visible or
2. you don't show it up at all until the visibility of the window
changes back to visible.
--
frank hellenkamp | interface designer
solmsstraße 7 | 10961 berlin
+49.30.49 78 20 70 | tel
+49.176.32 13 88 89 | mbl
+49.3212.100 35 22 | fax
jo...@depagecms.net
http://depage.net | bureau
http://depagecms.net | content management
http://immerdasgleiche.de | read
http://everydayisexactlythesame.net | see
signature.asc
Description: OpenPGP digital signature
Re: [whatwg] Proposal for a tab visibility API
Sorry for the delayed reply. I sent a number of responses over the past week, but it just came to my attention that due to some kind of mailing-list snafu, they never actually were sent out. I've attempted to bring all of my replies into this one message. Sorry for the impression that I had abandoned this thread--that was not my intention! Regarding the fact that background tabs aren't necessarily invisible: - On December 8, Boris Zbarsky wrote: There is no such guarantee for background tabs. For example, browsers may show tab previews in various contexts (Panorama in Firefox 4, e.g.). - The point of the API, as proposed, is that page scripts will know when their content is guaranteed to be invisible to the user--that is, the API will not provide a false positive about invisibility. However, the API may provide false negatives about invisibility, for reasons many others on this thread have been pointed out (including different windowing systems, multiple monitors, partial transparency, etc.). The easiest way to achieve this guarantee is to only consider a tab hidden when it is a background tab within* *a window. The window itself, of course, may be on a little-noticed second monitor, partially obscured, etc. But as you point out, there are still some edge cases where even a background tab is visible. In this specific example, I think the right answer would be to have an additional visibility value of preview, which, for the purposes of the isVisible property, would be considered a hidden state. There are some cases where a tab would consider a tab preview to be hidden (like the puzzle timer use case) and some cases where it would be considered visible (like the video playing use case). This would allow web developers to decide for themselves how they wanted to respond to that case. Regarding the additional abuse potential: -- On December 8th, Boris Zbarksy wrote: I'd really appreciate some comment on this. I'm pretty worried about adding features that we then have to start working around people abusing almost immediately... - Although I agree that there is some additional potential for abuse, I don't think it's a particularly large incremental potential. Sites that want to be annoying already have a very large toolbox today. Sites today could easily hook up a script that detects inactivity on a tab (e.g. lack of scrolling or mouse movement) and pops an alert, refocussing the tab. In practice, this is not a common occurrence--users can vote with their address bar and avoid sites that are needlessly annoying. There would be some easy defenses browser implementors could enact if this focus-grabbing did indeed become a problem. For example, code running in response to a visibilitychange event could be forbidden to open an alert (something that would be easy for moderately-savvy developers to circumvent via a setTimeout). Additionally, if a site pops multiple alerts when the tab is hidden, the alert shown to the user could contain an additional option to Prevent this site from grabbing focus in the future that would not allow alerts when the tab is hidden. Although there is some additional opportunity for abuse, I think that it is not particularly large, possible to defend against if necessary, and outweighed by the advantages such an API would provide to legitimate web developers. Regarding the video player use case from the initial proposal: - On December 8th, Maciej Stachowiak wrote: This use case can be handled without help from the page. In Safari, video (whether through media elements or plugins) won't start playing when a user opens a tab in the background, until the user switches to that tab. - Although what you describe satisfies the specific use case, it doesn't address the more general use case of animations (either explicit via javascript or via CSS Animations) or content that is not a plugin/video file. Regarding solving the use cases that cannot be addressed currently: -- On December 8th, Maciej Stachowiak wrote: That leaves the following use cases: * 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 page wants to detect when it is being prerendered so it can behave appropriately. I am not sure what the third needs exactly, but it seems like first two could be better served with an API that sets a timer which will only fire when the page is visible. That kind of API might be easier to use right, and avoids the need for JS to run when switching tabs, just to cancel and restart timers. - Although that API might be easier to use correctly (I don't know if I'm convinced), note that it would still have the same abuse concerns as the proposed API. A website developer determined to be annoying
Re: [whatwg] Proposal for a tab visibility API
Am 08.12.2010, 23:09 Uhr, schrieb Aryeh Gregor simetrical+...@gmail.com: On Wed, Dec 8, 2010 at 2:47 PM, Alex Komoroske komoro...@chromium.org wrote: =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. Should be visibilitychange rather than visibilitychanged, to match change, cuechange, durationchange, formchange, ratechange, readystatechange, and volumechange (I didn't expect so many . . .). On Wed, Dec 8, 2010 at 2:57 PM, Boris Zbarsky bzbar...@mit.edu wrote: 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. That sounds like it would probably eclipse all other use-cases in popularity. More sites have ads with timers on them than contain puzzle games or poll for dynamic content. Is there any way for browsers to dodge this while still serving the other use-cases? Or do we just figure that users can just leave the site or do per-site blocking if it gets too annoying, so it's not a big problem? Maybe we can disallow the visibilitychange event to produce any dialogs or anything else that could give focus?
Re: [whatwg] Proposal for a tab visibility API
On Fri, Dec 10, 2010 at 1:14 PM, Dennis Joachimsthaler den...@efjot.de wrote:
Maybe we can disallow the visibilitychange event to produce any dialogs
or anything else that could give focus?
window.onvisibilitychange = function(e) {
setTimeout(function() {
alert(Worked around!);
}, 0);
};
Or would browsers be able to track that the code was initially
triggered from visibilitychange? (including when programmatically
creating and dispatching another DOM events, instead of or in addition
to the setTimeout?)
--
Thomas Broyer
/tɔ.ma.bʁwa.je/
Re: [whatwg] Proposal for a tab visibility API
Am 09.12.2010 00:12 schrieb Boris Zbarsky: On 12/8/10 5:29 PM, Markus Ernst wrote: Thus, I'd consider an api for detecting the visibility state of every HTML element useful (totally visible, partially visible, hidden - or a percentage value). This is pretty hard to implement, in general. For example, if I put another window over the browser window then whether the content in the browser is visible depends on the exact app running in that window, and on the parts of it overlapping the browser content, right? Sure. Some applications might even be partially transparent, like some fancy-skinned media players.
Re: [whatwg] Proposal for a tab visibility API
Am 09.12.2010 07:12 schrieb Boris Zbarsky: 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. I'd really appreciate some comment on this. I'm pretty worried about adding features that we then have to start working around people abusing almost immediately... I assume that the abuse potential here is about the same as for onunload. Regarding ads, I assume that providing some kind of visibility API could also lead to better ads. Ad authors could make their ads stop executing when invisible. One main annoyance about ads is their resource consumption, thus ad blockers could provide a setting Block content from ad providers who don't stop the execution of hidden ads. Which would allow their users to block annoying resource consumers, while not blocking good ads, which their favorite websites might depend on.
Re: [whatwg] Proposal for a tab visibility API
i'm not sure i'm a fan. From work on the nokia n8x0/n900, we wanted to be able to stop things when the screen blanked. During this case the active tab was still the active tab, but since the screen was blanked, the user couldn't see it. That said, if a video is offscreen, partially offscreen, overlapped, then you have strange behaviors to worry about. I like trying to full screen a video on a secondary screen, and am perpetually annoyed by video players which kill themselves when they lose focus or similar. While we actually developed the n8x0/n900 browser, I complained about the case of a video where all I wanted was the audio. Right now I'm sitting in my apartment. There's a TV on which is showing BBC. There's also a stereo system which is playing the corresponding audio for the BBC content. They are both connected to a single DVR which is decoding the Video for the TV (SCART - *sigh*) and Audio for the Stereo (fiber audio). I am *not* watching the BBC, I'm staring at my MBP and typing to you. My focus is on this GMail window. *BUT* my ears are listening to the BBC from my stereo. The TV in fact has multiple inputs, it can also take DVI in from another Mac. If the TV where to tell the DVR to stop playing the BBC or the DVR were to decide to stop playing the BBC because the TV told it that it was no longer showing the BBC, I'd be annoyed. Because I'm *listening* to the BBC. The fact that the BBC isn't *visible* to me doesn't mean that I don't want the content to play. And every time someone gets *clever* and breaks my usecase, I cry. Now you might say that we can trust the people given the API to only use it for the right reasons. But I've been living with the web for a while, and I hope you have too. Note that mozilla has proposed a mozAnimation JS API. Are you sure that the game use case can't just use that? I think this is a perfect use case for that. If that's the case, then I don't think we need this, but can instead work on getting that API ready for more public consumption.
Re: [whatwg] Proposal for a tab visibility API
Markus Ernst derer...@gmx.ch schrieb am Thu, 09 Dec 2010 09:52:43 +0100: Regarding ads, I assume that providing some kind of visibility API could also lead to better ads. Ad authors could make their ads stop executing when invisible. Browser makers can do that already with less abuse possibilities. -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
[whatwg] Proposal for a tab visibility API
Hi all, On the Chromium team we’ve identified a couple of use cases that we’d like to address with a simple API, and we’d love your feedback. In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, although some heuristics do exist (like detecting mousemove events). In the future, there may be cases where such detection is even more important, for example in the prerendering feature ( http://code.google.com/p/chromium/issues/detail?id=61745) that Chromium is currently in the early stages of experimentation with. ==Use cases== * 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). * A page wants to detect when it is being prerendered so it can behave appropriately. * A page wants to detect when it is moving into or out of the back-forward cache. 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 ==Strawman API== What follows is a proposed API that fits the requirements. Note that another route would be to attempt a mostly-compatible extension of Mozilla’s existing pageshow and pagehide events, which would not necessarily be perfectly backwards compatible. =document.visibility= A read-only property that returns a string, one of: * “visible” : the tab is focused in its window * “hidden” : the tab is backgrounded within its window * “prerender” : the tab is currently being loaded in an off-screen tab, and may never be shown to the user. * “cache” : the tab is currently in the back-forward-cache. Note that in Mozilla’s current implementation, document.visibility would never actually be “cache” because Javascript cannot execute when in the cache. In the future, the list of possible values may be extended. Of these states in this list, all except “visible” are considered to be hidden. Developers can use the existence of this property to know that they can rely on the rest of this API, too. =document.isVisible= A simple convenience read-only property that returns a boolean. Returns true if document.visibility’s current value is in the set of visibility states considered to be visible (for the first iteration of this API, that would only include the “visible” state). =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibility 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. Thoughts or comments are welcome. --Alex Komoroske
Re: [whatwg] Proposal for a tab visibility API
On 12/8/10 2:47 PM, Alex Komoroske wrote: * A page wants to detect when it is moving into or out of the back-forward cache. This is covered by pagehide/pageshow events, as you note; note that the bfcache visibility state has some big differences from the other invisible states, as currently implemented. Maybe we should be trying to converge them, but I'm not convinced. There are several issues we should keep in mind as we work on this: 1) background tab is pretty narrow. Minimized windows, windows that aren't on the current desktop, etc, have all the same problems. 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. A read-only property that returns a string, one of: * “visible” : the tab is focused in its window And certain conditions in the window, ideally; though I can see leaving that to a further iteration of the API. * “cache” : the tab is currently in the back-forward-cache. Note that in Mozilla’s current implementation, document.visibility would never actually be “cache” because Javascript cannot execute when in the cache. Yes, but javascript running in other windows can touch the cached JS objects, no? -Boris
Re: [whatwg] Proposal for a tab visibility API
On Wed, 08 Dec 2010 19:47:34 -, Alex Komoroske komoro...@chromium.org wrote: Hi all, On the Chromium team we’ve identified a couple of use cases that we’d like to address with a simple API, and we’d love your feedback. In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, Minor semantic nitpick: please use the term /does not have focus/ rather than /is a background tab/, as the latter is misleading in window managers that don't use tabs to represent (all) windows. [Ninja'd] although some heuristics do exist (like detecting mousemove events). In the future, there may be cases where such detection is even more important, for example in the prerendering feature ( http://code.google.com/p/chromium/issues/detail?id=61745) that Chromium is currently in the early stages of experimentation with. ==Use cases== * 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. Fair 'nuff (though I stress the importance of Web IDL APIs like this being specified separately from HTML). * A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user. I argue that dynamic content should be declared as such. HTTP can hint at expiry of content, allowing UAs to automagically refetch content, but still allowing users to have the final say and set reasonable limits and take bandwidth constraints into consideration. I may not want to download that ad every two seconds over my metered mobile ad hoc network. * 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). I don't see how autoplaying videos relate to Web IDL, but this is covered in other specifications. Autoplay is quite annoying, and there are other reasons for not automatically following links in pages and playing media recently downloaded, but I'm going OT. * A page wants to detect when it is being prerendered so it can behave appropriately. * A page wants to detect when it is moving into or out of the back-forward cache. Pass. Remember to take note of the existing SIGTSTP, in case there's anything to learn from history. 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 Make a note of job/task managers potentially suspending unneded jobs, such as hidden/detached/backgrounded document (e.g. PDF, HTML) renderers. ==Strawman API== What follows is a proposed API that fits the requirements. Note that another route would be to attempt a mostly-compatible extension of Mozilla’s existing pageshow and pagehide events, which would not necessarily be perfectly backwards compatible. =document.visibility= A read-only property that returns a string, one of: * “visible” : the tab is focused in its window * “hidden” : the tab is backgrounded within its window Foremost, this makes more assumptions about the window management of the target system. Also, why would it be useful to know the focus of a tab inside of a window which may or may not be focused itself? =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibility 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. A property of visibilitychanged that hints at whether the program will continue executing or not.
Re: [whatwg] Proposal for a tab visibility API
On Wed, Dec 8, 2010 at 2:47 PM, Alex Komoroske komoro...@chromium.org wrote: =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. Should be visibilitychange rather than visibilitychanged, to match change, cuechange, durationchange, formchange, ratechange, readystatechange, and volumechange (I didn't expect so many . . .). On Wed, Dec 8, 2010 at 2:57 PM, Boris Zbarsky bzbar...@mit.edu wrote: 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. That sounds like it would probably eclipse all other use-cases in popularity. More sites have ads with timers on them than contain puzzle games or poll for dynamic content. Is there any way for browsers to dodge this while still serving the other use-cases? Or do we just figure that users can just leave the site or do per-site blocking if it gets too annoying, so it's not a big problem?
Re: [whatwg] Proposal for a tab visibility API
Am 08.12.2010 21:40 schrieb Bjartur Thorlacius: On Wed, 08 Dec 2010 19:47:34 -, Alex Komoroske In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, Minor semantic nitpick: please use the term /does not have focus/ rather than /is a background tab/, as the latter is misleading in window managers that don't use tabs to represent (all) windows. [Ninja'd] I am not too much familiar with the terminology here, but I humbly think that not having focus does not necessarily mean a window is not visible. I often have more than one visible window; maybe one where I am currently working, and another one at the side with a football game streamed or whatever. I wouldn't like the football stream to be stopped when this window looses focus. But when the stream gets totally hidden, be it that I open a new tab in the same window, or place some other window in front of it, the streaming application might want to save bandwidth by pausing the streaming of the visuals, while streaming on the audio. Thus, I'd consider an api for detecting the visibility state of every HTML element useful (totally visible, partially visible, hidden - or a percentage value).
Re: [whatwg] Proposal for a tab visibility API
On 12/8/10 5:29 PM, Markus Ernst wrote: Thus, I'd consider an api for detecting the visibility state of every HTML element useful (totally visible, partially visible, hidden - or a percentage value). This is pretty hard to implement, in general. For example, if I put another window over the browser window then whether the content in the browser is visible depends on the exact app running in that window, and on the parts of it overlapping the browser content, right? -Boris
Re: [whatwg] Proposal for a tab visibility API
On 12/8/10 5:55 PM, Alex Komoroske wrote: 1) background tab is pretty narrow. Minimized windows, windows that aren't on the current desktop, etc, have all the same problems. In general this can be very challenging to do correctly, as you allude to, and others later in the thread mention. What about windows on a second monitor that are partially obscured by another window? Fully obscured? I explicitly left those out of my list, yes, because they are rather difficult to detect. This initial API aims to allow developers to detect the obvious cases where they are guaranteed that their content is not visible at all. There is no such guarantee for background tabs. For example, browsers may show tab previews in various contexts (Panorama in Firefox 4, e.g.). 2) There is some potential for abuse (e.g. putting up dialogs to make yourself the active tab if you determine that you aren't, though perhaps this is a quality of implementation issue). I can particularly see things like ads doing this so you don't just switch to a different tab while they're running. I'd really appreciate some comment on this. I'm pretty worried about adding features that we then have to start working around people abusing almost immediately... -Boris
Re: [whatwg] Proposal for a tab visibility API
On Dec 8, 2010, at 11:47 AM, Alex Komoroske wrote: Hi all, On the Chromium team we’ve identified a couple of use cases that we’d like to address with a simple API, and we’d love your feedback. In particular, there is currently no good way for a web page to detect that it is a background tab and is thus completely invisible to the user, although some heuristics do exist (like detecting mousemove events). In the future, there may be cases where such detection is even more important, for example in the prerendering feature (http://code.google.com/p/chromium/issues/detail?id=61745) that Chromium is currently in the early stages of experimentation with. ==Use cases== * 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). This use case can be handled without help from the page. In Safari, video (whether through media elements or plugins) won't start playing when a user opens a tab in the background, until the user switches to that tab. * A page wants to detect when it is moving into or out of the back-forward cache. This use case is already handled with events specific to the back/forward cache (pagehide and pageshow). That leaves the following use cases: * 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 page wants to detect when it is being prerendered so it can behave appropriately. I am not sure what the third needs exactly, but it seems like first two could be better served with an API that sets a timer which will only fire when the page is visible. That kind of API might be easier to use right, and avoids the need for JS to run when switching tabs, just to cancel and restart timers. Also I wonder if pagehide and pageshow could be broadened to help the prerendering use case. It seems a bit speculative to make API just so Web pages can find out about an experimental feature being used. Regards, Maciej 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 ==Strawman API== What follows is a proposed API that fits the requirements. Note that another route would be to attempt a mostly-compatible extension of Mozilla’s existing pageshow and pagehide events, which would not necessarily be perfectly backwards compatible. =document.visibility= A read-only property that returns a string, one of: * “visible” : the tab is focused in its window * “hidden” : the tab is backgrounded within its window * “prerender” : the tab is currently being loaded in an off-screen tab, and may never be shown to the user. * “cache” : the tab is currently in the back-forward-cache. Note that in Mozilla’s current implementation, document.visibility would never actually be “cache” because Javascript cannot execute when in the cache. In the future, the list of possible values may be extended. Of these states in this list, all except “visible” are considered to be hidden. Developers can use the existence of this property to know that they can rely on the rest of this API, too. =document.isVisible= A simple convenience read-only property that returns a boolean. Returns true if document.visibility’s current value is in the set of visibility states considered to be visible (for the first iteration of this API, that would only include the “visible” state). =visibilitychanged= A simple event, fired at the document object immediately after document.visibility transitions between visibility states. The event has a property, fromState, that is set to the value of document.visibility 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. Thoughts or comments are welcome. --Alex Komoroske
