Re: Proposal for a page visibility API

On Thu, Jan 20, 2011 at 1:24 PM, Drew Wilson <atwilson@google.com> wrote:

>
>
> On Thu, Jan 20, 2011 at 12:13 PM, Alex Komoroske <komoroske@chromium.org>wrote:
>
>> For clarity, I've included the current draft of the proposal below, which
>> incorporates the feedback from this thread.
>>
>>
>> ****
>>
>> There is currently no good way for a web page to detect that it is
>> completely invisible to the user (for example, that it is a background tab),
>> although some imperfect heuristics do exist. In the future, there may be
>> cases where such detection is even more important, for example in the
>> prerendering feature that Chromium is currently in the early stages of
>> experimentation with.
>>
>>
>> Use cases
>>
>> *  A page wants to detect when it is being prerendered so it can behave
>> appropriately.
>> *  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.
>> *  A web app that uses polling to fetch dynamic content can pause polling
>> when it knows the page is hidden from the user.
>> *  A streaming video site doesn’t want to start the video until the user
>> actually views the tab for the first time (i.e. video shouldn’t start
>> automatically if a user opens the tab in the background).
>> *  An in-browser collaborative editing environment wants to update a
>> user’s status to away when the editing surface is not visible to the user.
>> *  A web-based chat application wants to show the user notifications via
>> the Web Notification API when a message is received, but only when the page
>> is not visible to the user.
>>
>
> I wanted to point out that many of these use cases are covered adequately
> by document.focus()/document.blur(), which is what we currently use in Gmail
> to decide whether to mark the user as away, decide whether to display
> notifications, etc. In fact, I think the only two use cases that aren't
> already covered by the focus/blur notifications are:
>
> * Page wants to detect prerendering
> * Web app wants to stop updating when it's not visible.
>

Although I agree that onfocus/onblur provide a useful signal that's *similar
* to the proposed API, I think they don't fully cover all of these use cases
by themselves.  Critically, even if your page has received an onblur event,
that's no guarantee that it's not still visible (e.g. on another screen, or
just in a window that doesn't have focus).  In the game timer use case and
polling use case, the app can't stop updating the display (or incrementing
the counter) because although it's pretty likely it's invisible, it's not a
guarantee.

So although existing methods (e.g. onfocus/onblur or watching for mouse
movement) can get *close *to what this API provides, they still can't do it
exactly.


>
> In the latter case, I actually don't think your current definition of
> visible ("is the focused tab in some browser window somewhere, even if that
> window is completely obscured by other windows") adequately addresses that
> use case (either the page would just hook focus/blur(), or it would really
> want to know if its actually visible to the user, rather than just being the
> topmost tab in a completely obscured window.
>

The wording is intentionally vague to give implementations wiggle room for
the various corner cases that are hard to handle correctly, but the
intention is that implementations would do their best to ensure there would
be relatively few false positives for "visible" (and, critically, never any
false positives for "hidden").

>
> So I think it's valuable to allow pages to detect prerendering/preview
> rendering, but I'm wondering if a more focused API would address that use
> case more concisely?
>
> -atw
>
>