- From: Jonas Sicking <jonas@sicking.cc>
- Date: Sat, 1 Oct 2011 23:58:12 -0700
- To: Darin Fisher <darin@chromium.org>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, public-web-perf@w3.org
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 Sunday, 2 October 2011 06:59:10 UTC