- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 28 Sep 2011 19:43:01 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-web-perf@w3.org
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. Generally for state-property-plus-state-changing-event we schedule a task which when it runs first changes the state-property and then fires the event. That way the page can rely on the state never changing without first seeing an event. It might mean that the state is slightly out of date, but that doesn't seem like a big problem, especially here. / Jonas
Received on Thursday, 29 September 2011 02:43:58 UTC