W3C home > Mailing lists > Public > public-web-perf@w3.org > February 2012

RE: [Page Visibility] Navigate away behavior (was RE: TPAC 2011 Web Performance WG 2011-11-01)

From: Jatinder Mann <jmann@microsoft.com>
Date: Fri, 3 Feb 2012 20:02:53 +0000
To: "Boris Zbarsky (bzbarsky@mit.edu)" <bzbarsky@mit.edu>, "public-web-perf@w3.org" <public-web-perf@w3.org>, "arvind@google.com" <arvind@google.com>
Message-ID: <EE4C13A1D11CFA49A58343DE361B0B041370A928@TK5EX14MBXC252.redmond.corp.microsoft.com>
> What if the document is not in fact "unloading" but instead going into a history cache?
I feel we should actually add two additional states to visibilityState: "suspended" and "unloaded". "suspended" state would be returned when the page will be suspended such that script cannot be executed or events fired, e.g., history cache. The "unloaded" state would be returned when the page will be unloaded.

Both "suspended" and "unloaded" visibilityStates will correlated with the hidden attribute of document being true.

> I'd like to understand the use cases here before adding more complexity, honestly.
Let's discuss two scenarios: saving state and throttling CPU intensive activity. 

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.

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. In this case, a developer may wish to query visibilityState as well to find whether the specific state is "hidden" or "unloaded"/"suspended".

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.

>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.

Thanks,
Jatinder

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Thursday, February 02, 2012 6:49 PM
To: Jatinder Mann
Cc: arvind@google.com; public-web-perf@w3.org
Subject: Re: [Page Visibility] Navigate away behavior (was RE: TPAC 2011 Web Performance WG 2011-11-01)

On 2/2/12 7:52 PM, Jatinder Mann wrote:
> I don't think it makes sense to fire the visibilitychange event after the unload event - the unload event should be the last chance to run code prior to unloading.

That's fine.  The way I implemented it in Gecko is that visibilitychange fires from the same task as pagehide and unload, after pagehide and before unload.  I buy the argument about firing it before unload, but would prefer to fire after pagehide.

> We can consider firing the visibilitychange event synchronously before the unload from the same task.

That's the proposal, yes.

> If we are to fire the visibilitychange event prior to unloading, we may want to inform developers that this particular visibilitychange is occurring during the unload, so they can make a performance decision of whether or not to run code at that point. I recommend that when the visiblitychange event is fired when unloading, we also synchronously change the hidden attribute of Document to "unloading".

What if the document is not in fact "unloading" but instead going into a history cache?

I'd like to understand the use cases here before adding more complexity, honestly.

> As for pagehide and pageshow, if you're relying on visibilitychange to throttle work, wouldn't you want to fire the visibilitychange event prior to the pagehide/pageshow? For UAs that support traversing to and from session history entries, we would also want to specify the ordering of pagehide/pageshow, visibilitychange and unload. Of course, unload would be the last, so we really need to determine the order of the first two.

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?

But I'm not religious about this, honestly.  As long as visibilitychange fires either "inside" pageshow/pagehide or "outside" it, but consistently, I can live with it.

-Boris
Received on Friday, 3 February 2012 20:03:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 3 February 2012 20:03:32 GMT