RE: [PageVisibility] Are visibility change events synchronous?

I see your point. Though, the example may not be the best practice, I do agree some developers will hit that scenario. 

I think we're all in agreement that the event should fire synchronously. I will update the spec to state that the visibilitychange event will fire synchronously after .hidden/.visibilityState properties have been updated. 

Jatinder

-----Original Message-----
From: Jonas Sicking [mailto:jonas@sicking.cc] 
Sent: Thursday, October 06, 2011 3:13 PM
To: Jatinder Mann
Cc: Darin Fisher; Boris Zbarsky; public-web-perf@w3.org
Subject: Re: [PageVisibility] Are visibility change events synchronous?

Consider the following scenario:

A page wants to update it's contents every few minutes. It does so by making a XHR request to the server to load updated data. However in order to not waste CPU cycles or band width, it wants to only do this while the page is visible.

To do this, it sets up a interval timer using setInterval which runs ever 5 minutes. In the onvisibilitychange event handler, if the page is getting unhidden, it creates a XHR object and adds the necessary event handlers to it. If the page is being hidden, it aborts the XHR and nulls it out as to prevent stale or partial data from laying around.

In the interval callback, the page checks the hidden state, and if not hidden it calls .open/.send on the XHR object to load new data.

If the visibilitychange event is fired synchronously after the .hidden state changes, then this will work fine.

If however the event is fired asynchronously some time after the .hidden state changes, then this will only work most of the time. If the page is unlucky, the interval timer will fire betwee the .hidden state changs, but before the onvisibilitychange event handler fires and sets up the XHR object.

While we could say that people "shouldn't do that", people still will.
In general, whenever we have state properties and events which fire when they change, we should always fire the event synchronously after the state variable changes. That's how we do it in for example XMLHttpRequest, IndexedDB and FileAPI.

/ Jonas

On Wed, Oct 5, 2011 at 4:14 PM, Jatinder Mann <jmann@microsoft.com> wrote:
> 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 Thursday, 6 October 2011 23:12:56 UTC