[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 <svartman95 at gmail.com>wrote:

> 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.


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 <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.
>

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, 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).


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.


>
>
>  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'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?

>
>  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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20101220/3f4f4a32/attachment-0001.htm>

Received on Monday, 20 December 2010 07:21:54 UTC