[whatwg] Proposal for a tab visibility API

[Bjartur Thorlacius]

On Wed, 15 Dec 2010 19:27:51 -0000, Alex Komoroske
<komoroske at 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 <link>ed
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 "model"s 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, wall-clock keeps going.
> * A web app that uses polling to fetch dynamic content can pause polling
> when it knows the page is hidden from the user.
A suspended script can't phone home.
> * A page wants to detect when it is being prerendered so it can behave
> appropriately.
The only use case for this I can see is confusing users. That's probably
just me.
> 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 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.
>
IMO, the script should probably not be running in such cases, rather  
suspended
or not executed at all.

> [snip]
>
> On Fri, Dec 10, 2010 at 3:00 PM, Thomas Broyer <t.broyer at gmail.com>  
> wrote:
>
>> On Fri, Dec 10, 2010 at 1:14 PM, Dennis Joachimsthaler <dennis at 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?)
I was thinking more like disabling access to alert, even from other  
functions.