Re: [PageVisibility] Are visibility change events synchronous?

[Sorry for the slow reply.]

In Chromium, the two are inter-locked.  The visibility state is updated, and
then before returning to process other events, we dispatch the notification
that the visibility state changed.

-Darin


On Sat, Oct 1, 2011 at 11:58 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> The question is, does the property change from the same task as the
> event is fired? I.e. do you change the value of the property and then
> immediately and synchronously after that fire the event?
>
> Put it another way, if I schedule a setInterval which checks the value
> of the property, could it possibly see a changed value of the property
> before the event fires?
>
> / Jonas
>
> On Fri, Sep 30, 2011 at 10:15 PM, Darin Fisher <darin@chromium.org> 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.
> >
> > -Darin
> >
> > On Wed, Sep 28, 2011 at 7:25 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> >>
> >> If there is a visibility change, is the visibility change event fired
> >> synchronously?
> >>
> >> Note that this is sort of page-observable: a page could poll the
> >> visibilityState and see whether it matches the previous state without
> having
> >> seen an event.  Then again, it's hard to tell that situation apart from
> one
> >> where some other script called stopImmediatePropagation on the event and
> >> then dispatched a new event...
> >>
> >> My personal preference would be to allow or require asynchronous firing;
> >> the alternative involves, e.g. a tab switch triggering synchronous JS
> >> execution before it completes, which is not great for users navigating
> >> across tabs using the keyboard.
> >>
> >> -Boris
> >>
> >
> >
>

Received on Thursday, 6 October 2011 07:17:49 UTC