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!<div>
<br></div><div><div><br></div><div>Regarding the fact that background tabs aren't necessarily invisible:</div><div>-----</div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
On December 8, Boris Zbarsky wrote:</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<span class="Apple-style-span" style="border-collapse: collapse; color: rgb(80, 0, 80); font-family: arial, sans-serif; font-size: 13px; ">There is no such guarantee for background tabs. For example, browsers may show tab previews in various contexts (Panorama in Firefox 4, e.g.).</span></blockquote>
<div>-----</div><div><br></div><div><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><div>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.). </div>
<div><br></div><div>The easiest way to achieve this guarantee is to only consider a tab hidden when it is a background tab within<i> </i>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.</div>
</span></div><div><br></div><div>Regarding the additional abuse potential:</div><div>------<br><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
On December 8th, Boris Zbarksy wrote:</blockquote><meta charset="utf-8"><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
<span class="Apple-style-span" style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">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...</span> </blockquote>
</div><div>-----</div><div><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><div>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. </div>
<div><br></div><div>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. </div>
<div><br></div><div>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.</div>
</span></div><div><br></div><div>Regarding the video player use case from the initial proposal: </div><div>-----</div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
On December 8th, Maciej Stachowiak wrote:<br><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">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.</span></blockquote>
<div><br></div><div>-----</div><div><br></div><div><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">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. </span></div>
<div><br></div><div>Regarding solving the use cases that cannot be addressed currently:</div><div>------</div><div>On December 8th, Maciej Stachowiak wrote:</div><div><meta charset="utf-8"><div><blockquote><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">That leaves the following use cases:</span></font><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">* 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.<br>
</span></font><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">* A web app that uses polling to fetch dynamic content can pause polling when it knows the page is hidden from the user.<br>
</span></font><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">* A page wants to detect when it is being prerendered so it can behave appropriately.</span></font><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;"><br>
</span></font><font class="Apple-style-span" color="#222222" face="arial, sans-serif"><span class="Apple-style-span" style="border-collapse: collapse;">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.</span></font></blockquote>
</div></div><div>-----</div><div><br></div><div><meta charset="utf-8"><div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">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 could register two timers--one that would not fire when the page is invisible, and one that would continue firing even when the page is invisible. The first would update some global variable with a timestamp every time it fires; the second would check to see if the timestamp was significantly more stale than the first's timer interval, and then could trigger a re-focussing alert. Of course, the other benefit you note is that this idea wouldn't require running javascript every time a user switches tabs, for this class of use cases. </div>
<div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">
The initial use cases listed might be unintentionally narrow. Another use case is:</div><div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">
* An in-browser collaborative editing environment wants to update a user's status to away when the tab is in the background.</div><div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">
<br></div><div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">(Although the timer API you mention could be used to address even this use case (indirectly) because it implicitly exposes the key information of whether the tab is invisible.) </div>
<div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><br></div><div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">
Regarding building on top of pagehide/pageshow API:</div><div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">----</div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
O<span class="Apple-style-span" style="font-family: arial; font-size: small; border-collapse: separate; color: rgb(0, 0, 0); ">n December 8th, Maciej Stachowiak wrote:<br></span><span class="Apple-style-span" style="font-family: arial; font-size: small; border-collapse: separate; color: rgb(0, 0, 0); "><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; ">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.</span></span></blockquote>
<div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><span class="Apple-style-span" style="font-family: arial; font-size: small; border-collapse: separate; color: rgb(0, 0, 0); ">-----</span></div>
<div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><span class="Apple-style-span" style="font-family: arial; font-size: small; border-collapse: separate; color: rgb(0, 0, 0); "><br>
</span></div><div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><span class="Apple-style-span" style="font-family: arial; font-size: small; border-collapse: separate; color: rgb(0, 0, 0); "><meta charset="utf-8"><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><div>
The motivator that got us first thinking about this API in earnest was the prerendering case--although the other use cases, which we also think are important, appear to dovetail nicely. An initial draft attempted to piggyback on the existing pageshow/pagehide API. In practice it was extremely difficult to do correctly, because the visibility/prerender-status of the tab is independent of the load event. The user could click on the predicted link before load fires, or after it has fired. In contrast, the existing pageshow/pagehide API guarantees that pageshow fires after load (at least according to this page: <a href="https://developer.mozilla.org/En/Using_Firefox_1.5_caching" target="_blank" style="color: rgb(53, 66, 88); ">https://developer.mozilla.org/En/Using_Firefox_1.5_caching</a>).</div>
<div><br></div><div>I would be interested to hear more about a plan that could use the existing pageshow/pagehide API for prerendering in a way that is backwards compatible.</div><div><br></div><div>--Alex</div></span></span></div>
<div style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; "><span class="Apple-style-span" style="font-family: arial; font-size: small; border-collapse: separate; color: rgb(0, 0, 0); "><br>
</span></div><meta charset="utf-8"></div><div><div class="gmail_quote">On Fri, Dec 10, 2010 at 3:00 PM, Thomas Broyer <span dir="ltr"><<a href="mailto:t.broyer@gmail.com">t.broyer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Fri, Dec 10, 2010 at 1:14 PM, Dennis Joachimsthaler <<a href="mailto:dennis@efjot.de">dennis@efjot.de</a>> wrote:<br>
><br>
> Maybe we can disallow the "visibilitychange" event to produce any dialogs<br>
> or anything else that could give focus?<br>
<br>
</div>window.onvisibilitychange = function(e) {<br>
setTimeout(function() {<br>
alert("Worked around!");<br>
}, 0);<br>
};<br>
<br>
Or would browsers be able to track that the code was initially<br>
triggered from visibilitychange? (including when programmatically<br>
creating and dispatching another DOM events, instead of or in addition<br>
to the setTimeout?)<br>
<font color="#888888"><br>
--<br>
Thomas Broyer<br>
/t<a href="http://xn--nna.ma.xn--bwa-xxb.je/" target="_blank">ɔ.ma.bʁwa.je/</a><br>
</font></blockquote></div><br></div></div>