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

I would like to close on our discussion of the specified visibilitychange behavior when navigating away or closing the browser tab/window. We haven't closed on the exact behavior and Arvind hasn't chimed in yet on his thoughts on this change.

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. We can consider firing the visibilitychange event synchronously before the unload from the same task.

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". A developer can treat the "unloading" as "hidden" during the unload.

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.

Thanks,
Jatinder

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Tuesday, November 15, 2011 7:58 PM
To: Jatinder Mann
Cc: public-web-perf@w3.org
Subject: Re: [Page Visibility] Navigate away behavior (was RE: TPAC 2011 Web Performance WG 2011-11-01)

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 Friday, 3 February 2012 00:54:24 UTC