- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 6 Oct 2011 17:10:46 -0700
- To: Jatinder Mann <jmann@microsoft.com>
- Cc: Darin Fisher <darin@chromium.org>, Boris Zbarsky <bzbarsky@mit.edu>, "public-web-perf@w3.org" <public-web-perf@w3.org>
On Thu, Oct 6, 2011 at 4:12 PM, Jatinder Mann <jmann@microsoft.com> wrote: > 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. Cool! And I agree that it's not best practice, but that people will do it anyway :) Specifically what you want to say is that a task is scheduled, and when that task runs it synchronously sets the .hidden/.visibilityState and then fires the event. I.e. we want the task itself to run asynchronously, but we want various things that happen in the task to happen synchronously relative each other. I hope that makes sense? / Jonas
Received on Friday, 7 October 2011 00:11:43 UTC