- From: Jatinder Mann <jmann@microsoft.com>
- Date: Wed, 5 Oct 2011 23:14:53 +0000
- To: Jonas Sicking <jonas@sicking.cc>, Darin Fisher <darin@chromium.org>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, "public-web-perf@w3.org" <public-web-perf@w3.org>
I agree that we should always change the properties (document.hidden and document.visibilityState) prior to firing the event. However, I don't know if there is value in ensuring those two things happen synchronously. As long as the properties are correct and can be relied upon by the time the event has fired, I think we should be fine. Jatinder -----Original Message----- From: public-web-perf-request@w3.org [mailto:public-web-perf-request@w3.org] On Behalf Of Jonas Sicking Sent: Saturday, October 01, 2011 11:58 PM To: Darin Fisher Cc: Boris Zbarsky; public-web-perf@w3.org Subject: Re: [PageVisibility] Are visibility change events synchronous? 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 Wednesday, 5 October 2011 23:15:29 UTC