Hi Bjartur,<div><br></div><div>Thanks for your comments. I've replied inline.<br><br><div class="gmail_quote">On Sun, Dec 19, 2010 at 8:11 PM, Bjartur Thorlacius <span dir="ltr"><<a href="mailto:svartman95@gmail.com">svartman95@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 Wed, 15 Dec 2010 19:27:51 -0000, Alex Komoroske<br>
<<a href="mailto:komoroske@chromium.org" target="_blank">komoroske@chromium.org</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regarding the fact that background tabs aren't necessarily invisible:<br>
-----<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On December 8, Boris Zbarsky wrote:<br>
</blockquote>
<br>
There is no such guarantee for background tabs. For example, browsers may<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
show tab previews in various contexts (Panorama in Firefox 4, e.g.).<br>
</blockquote>
<br>
-----<br>
<br>
The point of the API, as proposed, is that page scripts will know when their<br>
content is guaranteed to be invisible to the user--that is, the API will not<br>
provide a false positive about invisibility. However, the API may provide<br>
false negatives about invisibility, for reasons many others on this thread<br>
have been pointed out (including different windowing systems, multiple<br>
monitors, partial transparency, etc.).<br>
<br>
The easiest way to achieve this guarantee is to only consider a tab hidden<br>
when it is a background tab within* *a window. The window itself, of<br>
course, may be on a little-noticed second monitor, partially obscured, etc.<br>
</blockquote></div>
I don´t see how that information is useful. Now, you have to define<br>
'window'<br>
and 'tab' differently and define a background state of the latter. Do<br>
multiple<br>
non-backgrounded (attached) tabs in a window need special treatment? If<br>
you use the term 'tab' anywhere it _will_ be confused with the UI metaphor,<br>
causing confusion with the approach to hierarchical window management.<br>
I don't understand what the term 'tab' means to you. To me a tab is a<br>
window.</blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But as you point out, there are still some edge cases where even a<br>
background tab is visible. In this specific example, I think the right<br>
answer would be to have an additional visibility value of "preview", which,<br>
for the purposes of the isVisible property, would be considered a hidden<br>
state. There are some cases where a tab would consider a tab preview to be<br>
hidden (like the puzzle timer use case) and some cases where it would be<br>
considered visible (like the video playing use case). This would allow web<br>
developers to decide for themselves how they wanted to respond to that case.<br>
<br>
</blockquote></div>
Or, one could mark them up semantically. A video player depends on<br>
visibility and audibility and an UA should thus not play video unless it<br>
fulfill said requirements. There is also the case of an optional <link>ed<br>
soundtrack, which won´t prevent visual playback. In case of an interactive<br>
game such as a puzzle, it shouldn't even execute while not focused. IMHO,<br>
programs should be stalled (think SIGTTOU) while dynamic requirements can't<br>
be fulfilled.<br>
<br>
In theory, we'd just use blocking operations, but they've been deemed to hard<br>
for JavaScript.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regarding the additional abuse potential:<br>
</blockquote></div>
Implementations of my counterproposal don't even notify scripts about 'tab'<br>
visibility changes, and additionally suspend unimportant scripts, rendering<br>
current focus-stealing methods useless.<br></blockquote><div><br></div><div>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?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Arguably, it could still be useful to throw an event upon suspension. alert could<br>
potentially be removed from window prior to launching the event and the scripts<br>
given a timeout, before they get suspended forcibly. I don't know the inner<br>
workings of JavaScript implementations to realize whether this could be<br>
circumvented by cloning new instances of alert, or whether implementations<br>
could simply disable access to potentially harmful methods at an higher level.<div class="im"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regarding the video player use case from the initial proposal:<br>
-----<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On December 8th, Maciej Stachowiak wrote:<br>
This use case can be handled without help from the page. In Safari, video<br>
(whether through media elements or plugins) won't start playing when a user<br>
opens a tab in the background, until the user switches to that tab.<br>
</blockquote>
<br>
<br>
-----<br>
<br>
Although what you describe satisfies the specific use case, it doesn't<br>
address the more general use case of animations (either explicit via<br>
javascript or via CSS Animations) or content that is not a plugin/video<br>
file.<br>
<br>
</blockquote></div>
I argue that there are two potentially viable solutions: Implementations<br>
exploiting more methods á la Safari, stopping animations or apps declaring<br>
dependencies on various things like visibility and audibility. There are<br>
previous proposals regarding throwing CSS media events upon change, which<br>
could potentially be integrated with this.<br>
<br>
The whole things smells of over-engineering. A resource of MIME media type<br>
"audio" obviously can't be rendered without audibility, "image" resources<br>
sans (2D) visibility nor "model" resources sans 3D visibility. "Text"<br>
resources can be rendered both visually and aurally, and "model"s can also<br>
be rendered to 2D displays, as long they're interactive (they're redrawable<br>
and user input is accessible).</blockquote><div><br></div><div>Although I agree that in some limited cases the correct behavior is clear, in practice there is a lot of gray area for many common cases. A multi-user collaborative puzzle should continue executing even when in the background (perhaps another player made a move that should play a sound to alert this user of the new move); a single-player puzzle might not need to execute at all when backgrounded. The more complex the web app, the more likely that the precise needs for pausing can't be met precisely with simple "semantic" directives to the browser.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Regarding solving the use cases that cannot be addressed currently:<br>
------<br>
On December 8th, Maciej Stachowiak wrote:<br>
<br>
That leaves the following use cases:<br>
* A puzzle game has a timer that keeps track of how long the user has taken<br>
to solve the puzzle. It wants to pause the timer when the user has hidden<br>
the tab.<br>
</blockquote></div>
The counter is paused while the script's suspended, wall-clock keeps going.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* A web app that uses polling to fetch dynamic content can pause polling<br>
when it knows the page is hidden from the user.<br>
</blockquote></div>
A suspended script can't phone home.<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* A page wants to detect when it is being prerendered so it can behave<br>
appropriately.<br>
</blockquote></div>
The only use case for this I can see is confusing users. That's probably<br>
just me.</blockquote><div><br></div><div>I'm not sure that I understand this point. Given the existence of a pre-rendering feature, how would providing information to the page about whether it is being pre-rendered lead to confusion of users? </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am not sure what the third needs exactly, but it seems like first two<br>
could be better served with an API that sets a timer which will only fire<br>
when the page is visible. That kind of API might be easier to use right, and<br>
avoids the need for JS to run when switching tabs, just to cancel and<br>
restart timers.<br>
<br>
-----<br>
<br>
Although that API might be easier to use correctly (I don't know if I'm<br>
convinced), note that it would still have the same abuse concerns as the<br>
proposed API. A website developer determined to be annoying could register<br>
two timers--one that would not fire when the page is invisible, and one that<br>
would continue firing even when the page is invisible. The first would<br>
update some global variable with a timestamp every time it fires; the second<br>
would check to see if the timestamp was significantly more stale than the<br>
first's timer interval, and then could trigger a re-focussing alert. Of<br>
course, the other benefit you note is that this idea wouldn't require<br>
running javascript every time a user switches tabs, for this class of use<br>
cases.<br>
<br>
</blockquote></div>
IMO, the script should probably not be running in such cases, rather suspended<br>
or not executed at all.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
[snip]<div class="im"><br>
<br>
On Fri, Dec 10, 2010 at 3:00 PM, Thomas Broyer <<a href="mailto:t.broyer@gmail.com" target="_blank">t.broyer@gmail.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Dec 10, 2010 at 1:14 PM, Dennis Joachimsthaler <<a href="mailto:dennis@efjot.de" target="_blank">dennis@efjot.de</a>><br>
wrote:<br>
><br>
> Maybe we can disallow the "visibilitychange" event to produce any dialogs<br>
> or anything else that could give focus?<br>
<br>
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>
</blockquote></div></blockquote>
I was thinking more like disabling access to alert, even from other functions.<br>
</blockquote></div><br></div>