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

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

From: Jatinder Mann <jmann@microsoft.com>
Date: Wed, 16 May 2012 01:09:31 +0000
To: Arvind Jain <arvind@google.com>, Boris Zbarsky <bzbarsky@mit.edu>
CC: Sreeram Ramachandran <sreeram@google.com>, "public-web-perf@w3.org" <public-web-perf@w3.org>
Message-ID: <AE5FFD9402CD4F4785E812F2C9929D6504EFA66E@SN2PRD0310MB383.namprd03.prod.outlook.com>
> So then, let's settle on calling the visibility handler after pagehide, and also before 
> pageshow if the page is coming from the pagecache.  Also, given that the event is 
> fired after pagehide, we don't need to overload the visibilityState attribute with 
> states like "suspended" or "unloaded". So let's remove those two states from 
>the list (https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/PageVisibility/Overview.html
> #dom-document-visibilitystate).
> Please comment if you have any concerns.
> Arvind

Regarding ISSUE-8, seems like we have consensus to fire the visibilitychange event after pagehide and before pageshow. I am assuming this also means to fire the visibilitychange event prior to the firing of the unload event? I will make the necessary spec updates to reflect this behavior. 

About the additional proposed visibiltyState attribute values, I recommend we should at least keep "unloaded". The purpose of the visibilityState attribute is to provide more granular data on the current visibility state than the hidden Boolean does. This state will allow a developer to make an informed decision of whether or not to run additional code during the unload process. I can't see any obvious problems with including this data.

Received on Wednesday, 16 May 2012 01:10:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:01:12 UTC