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: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 02 Feb 2012 21:49:06 -0500
Message-ID: <4F2B4B22.2030509@mit.edu>
To: Jatinder Mann <jmann@microsoft.com>
CC: "arvind@google.com" <arvind@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
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, 

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

Received on Friday, 3 February 2012 02:49:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:32 UTC