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: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Tue, 15 May 2012 13:58:03 -0400
Message-ID: <4FB2992B.10608@mit.edu>
To: Sreeram Ramachandran <sreeram@google.com>
CC: public-web-perf@w3.org
On 5/15/12 1:21 PM, Sreeram Ramachandran wrote:
> On Tue, May 15, 2012 at 8:56 AM, Boris Zbarsky<bzbarsky@mit.edu>  wrote:
>> On 5/15/12 11:30 AM, Sreeram Ramachandran wrote:
>>> Do we need to clarify in the spec that the event fires between load
>>> and pageshow
>> There would be no visibility change event during an initial page load, if it
>> happened in a foreground tab, since the page starts out visible and there is
>> no visibility change.
> So, to be consistent, I think we should say that visibility change is
> NOT fired after pagehide in the case of a true unload

This would not be consistent, actually.  The reason is that load and 
unload are fundamentally asymmetric: while you can't get a reference to 
a document before the loading process starts, you _can_ keep a reference 
to the document after unload.

So there is no way to observe the transition from "no document" to 
"visible document" when the load starts if the document is loading in a 
foreground tab.  But there is very much a way to observe the transition 
from "visible document" to "invisible document" when the tab is unloading.

> thus distinguishing it from the case of a document going into the page
> cache.

Why would that be a useful distinction for purposes of this API?

> I.e., in a normal load/unload scenario, the document never sees a
> visibilitychange event.

This leads to documents that script has access to that go from being 
visible to not being visible without firing such an event...

Received on Tuesday, 15 May 2012 18:18:58 UTC

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