- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Fri, 03 Feb 2012 15:12:06 -0500
- To: Jatinder Mann <jmann@microsoft.com>
- CC: "public-web-perf@w3.org" <public-web-perf@w3.org>, "arvind@google.com" <arvind@google.com>
On 2/3/12 3:02 PM, Jatinder Mann wrote: > In the saving state case, you wish to save your application state whenever the page is no longer visible to the user. In this case, you wish to save state whenever the hidden attribute is true, regardless of whether you are going to the background tab, history cache or unloading. A developer would only look at the hidden attribute of document. Yes, agreed. > In the CPU throttling case, you only wish to throttle CPU activity when your page still has script activity, like the background tab. However, when you are unloading, you may not want to waste valuable cycles throttling work when you will be unloaded soon anyway. This is the part I'm not quite following. Why would throttling involve wasting cycles? Maybe I don't quite understand the scenarios you're worried about here.... > The API was designed such that document.hidden was the simple Boolean check for whether the page is visible or not and visibilityState for additional data on each state. Adding these two additional states to visibiltyState will only help developers make informed decisions, which I think is a good thing. I have no problem with adding more states per se; it's not hard to implement. I do worry about adding states developers don't expect or won't properly understand. That would interfere with the informed decision bit. "suspended" and "unloaded" might be ok, though. I could live with those. >> The reason I want to fire visibilitychange before pageshow and after pagehide is that: >> 1) The latter preserves the invariant that it actually triggers on visibility state changes: it fires after we're actually hidden. >> 2) The former preserves the general ordering of visibility changes and page show/hide. During a document load, for example, the document becomes visible (there is no event for this initial visibility change) and then fires pageshow sometime later, right? > > I see your point. I think we should define visibilitychange as occurring before pageshow and after pagehide. Additionally, we will need to specify that visibilitychange needs to occur after the beforeunload event. I believe this last may be automatic, but in case it's not I agree that it should be ordered this way. Sounds good! -Boris
Received on Friday, 3 February 2012 20:12:35 UTC