Re: [PageVisibility] Are visibility change events synchronous?

On Sun, Oct 2, 2011 at 3:51 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 10/1/11 1:15 AM, Darin Fisher wrote:
>
>> In Chromium, the visibility state (as WebKit sees it) is modified from
>> an IPC message (i.e., from a shallow call stack).  It is completely
>> asynchronous to actual tab changes that happen in a separate process.
>>
>
> Well, sure, but there could be other visibility-changing things that page
> script can trigger.  And in any case, this doesn't address the concern I
> actually raised, which was about page-visible visibility state changes, not
> user-visible visibility changes.  The two are pretty loosely correlated,
> obviously.
>
> In any case, here is what Gecko will be implementing if my currently
> proposed patch lands.  I believe the description below is a minimal one that
> defines the behavior in a way in which this spec should define it; the spec
> will need it or something like it if different behavior is decided on:
>
> 1)  visibilitychange events fire synchronously after the visibility state
> of the document changes.  There is no way to observe a document in a changed
> visibility state without the event having fired (though of course it may not
> have propagated to your listener yet).
>
> 2)  The visibility state of a document changes synchronously on page
> navigations.  In particular, it changes to hidden (if not already hidden)
> synchronously after the firing of the pagehide event and changes to visible
> as needed synchronously before the firing of the pageshow event.
>

This makes sense, although Chromium does not implement a back/forward page
cache.  Otherwise, it sounds like we will have compatible implementations.

-Darin



>
> 3)  In all other cases, visibility state changes happen directly off the
> event loop.
>
> -Boris
>