- From: Darin Fisher <darin@chromium.org>
- Date: Fri, 30 Sep 2011 22:15:03 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-web-perf@w3.org
Received on Saturday, 1 October 2011 05:15:37 UTC
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 Saturday, 1 October 2011 05:15:37 UTC