[whatwg] Proposal for a tab visibility API

[Glenn Maynard]

(Subscribed recently; sorry for breaking threading.)

On Wed, Dec 8, 2010 at 2:57 PM, Boris Zbarsky <bzbar... at mit.edu> wrote:
> 2)  There is some potential for abuse (e.g. putting up dialogs to make
>    yourself the active tab if you determine that you aren't, though
>    perhaps this is a quality of implementation issue).  I can
>    particularly see things like ads doing this so you don't just
>    switch to a different tab while they're running.

In practice, at least in FF and Chrome you can already do this:
alert() from window.onblur.  I've never seen that in the wild, though
that may be ABP blocking scripts that do it.  Making those dialogs
modal to the tab, as someone mentioned, seems like a solid fix for
this and most other problems with those dialogs.  So far the only
browser I've seen that does this well is Opera.  Hopefully, eventually
all modal interactions from a tab--login prompts, file open dialogs,
etc., will be modal to the tab; a tab should never be able to block
the whole window, just as a native application should not be able to
block the whole windowing system.  It's always frustrating to resume a
browser session and have to respond to several authentication prompts
before I can use other, unrelated tabs.

(Cute FF bug: alerting from onblur brings the tab back into focus,
*after* it's closed.  Zombie tab!  Seems to be fixed in 4.)

I think giving pages information that encourages them to pause
unnecessary scripts is a good thing; it's hard to complain about
background pages wasting resources with scripts when they're not given
the information they need to not do so.  This seems like a logical
extension of the window.onblur/onfocus extensions, which usually
aren't enough information.

On Wed, 15 Dec 2010 19:27:51 -0000, Alex Komoroske
<komoro... at chromium.org> wrote:
> 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.

This would mean sending events to every window when previews are
displayed, right?  That sounds like a performance pit--open a preview
display (which should be very quick) and windows with
previews-considered-visible behavior all start working at the same
time.

-- 
Glenn Maynard