[whatwg] Proposal for a tab visibility API

[Bjartur Thorlacius]

On 12/20/10, Alex Komoroske <komoroske at chromium.org> wrote:
> 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.
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 "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.
>
A multiplayer puzzle needs either focus and visibility (and'll use a network
connection when available) or a network connection and a notification
mechanism. The developer will be aware of what interfaces the app utilizes, and
declaring dependencies on interfaces he might otherwise take for granted might,
as a surplus, prompt him to think about accessibility issues that may rise when
the interfaces can't be used.

>
>>
>>
>>  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?
>
My misunderstanding. It cannot cause user-confusion. Ignore.