[whatwg] Proposal for a tab visibility API

[Dennis Joachimsthaler]

Am 08.12.2010, 23:09 Uhr, schrieb Aryeh Gregor <Simetrical+w3c at gmail.com>:

> On Wed, Dec 8, 2010 at 2:47 PM, Alex Komoroske <komoroske at chromium.org>  
> wrote:
>> =visibilitychanged=
>> A simple event, fired at the document object immediately after
>> document.visibility transitions between visibility states.
>
> Should be "visibilitychange" rather than "visibilitychanged", to match
> "change", "cuechange", "durationchange", "formchange", "ratechange",
> "readystatechange", and "volumechange" (I didn't expect so many . .
> .).
>
> On Wed, Dec 8, 2010 at 2:57 PM, Boris Zbarsky <bzbarsky 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.
>
> That sounds like it would probably eclipse all other use-cases in
> popularity.  More sites have ads with timers on them than contain
> puzzle games or poll for dynamic content.  Is there any way for
> browsers to dodge this while still serving the other use-cases?  Or do
> we just figure that users can just leave the site or do per-site
> blocking if it gets too annoying, so it's not a big problem?

Maybe we can disallow the "visibilitychange" event to produce any dialogs
or anything else that could give focus?