W3C home > Mailing lists > Public > public-web-perf@w3.org > November 2011

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Wed, 16 Nov 2011 16:57:39 +1300
Message-ID: <4EC334B3.6010907@mit.edu>
To: Jatinder Mann <jmann@microsoft.com>
CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
On 11/16/11 7:35 AM, Jatinder Mann wrote:

 > We will need a test case to test the spec statement that visibility
 > be hidden when defaultView is null. I will take that action item.

Thank you!

>> Gecko and Presto currently do not set defaultView to null when a document is navigated away from.
>
> The HTML5 defaultView spec requirements seem to not discuss when a document is navigated away - http://dev.w3.org/html5/spec/browsers.html#dom-document-defaultview. Is there any must requirements to change defaultView to null on navigate away?

As far as I can tell, no.

It's not clear to me whether there is a MUST-level requirement that the 
defaultView not change on navigation away.

Note that I feel that we should treat "navigated away" and "window 
closed" and "iframe removed from the DOM" similarly, by the way.

>> We do need to define ordering of that event with unload/pageshow/pagehide, of course.
>
> Yes, the ordering will need to be clearly defined. On the surface, it seems that the visibilitychange event should fire at the same time as the unload.

 From the same task, you mean?  I think that's the right behavior, yes. 
  The thing we need to define is whether it fires before or after 
unload, and similar for pagehide (and pageshow, for pages coming out of 
a document cache).

What Gecko currently implements is that:

1)  Immediately after firing a pagehide event the document's visibility 
state changes to "hidden" and a visibility change event is hired.  This 
all happens from a single task.

2)  When restoring a document from the document cache, the visibility 
state is set to whatever is relevant for the document's browsing context 
and a visibility change event is fired immediately before firing the 
pageshow event.  This all happens from a single task.

I'm open to changing the exact ordering there as needed, but we need to 
specify it at about that level of detail.  I also think that the 
ordering should be consistent between show and hide in that if the 
visibility state changes after pagehide then it should similarly change 
before pageshow.

-Boris
Received on Wednesday, 16 November 2011 03:58:15 UTC

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