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

Updating the title to clarify the discussion at hand.

>> Per the working group conference call, we felt that iframe visibility, 
>> though somewhat interesting, is something to consider in a future 
>> revision
>
>I'm fine with that.  That was raised as a question for the working group to consider, not an issue.

Excellent. We will consider this issue closed as there is consensus in the working group on the current design.

> The attached testcase shows that in WebKit navigating away from a document sets its defaultView to null.  For navigated-away-from documents, Chrome currently fails the MUST requirement listed above; see the iframe part of the attached testcase.  Is there a test in the test suite for this that it's already failing?

The defaultView statement in the section had been recently added, based on your feedback actually. 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.

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

> In any case, I strongly believe that for purposes of this API consistency in having navigated-away-from or otherwise unloaded documents claim to be hidden would be better than depending on the specifics of defaultView behavior on document navigation and browsing context discard.  This is especially so because the navigation section of HTML5 has not gotten much review yet and the defaultView behavior on navigation may well change from whatever it is right now.

I agree that we don't necessarily have to bootstrap this feature with the design of defaultView.

>The ability to write a single codepath if you want to hook visibility changes instead of having to listen to multiple events and manage interactions between them.

The more I think about it, I think there is value in providing a pattern where developers have the ability to save their state and throttle work solely based on visibility. Having the visibility change on navigate away and closing of a tab will allow developers that want to save state on visibility change to do so without also registering for existing end of session events like beforeunload and onload.

How do others in the working group feel about this proposed behavior?

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

Jatinder


-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Wednesday, November 09, 2011 10:59 AM
To: Jatinder Mann
Cc: public-web-perf@w3.org
Subject: Re: TPAC 2011 Web Performance WG 2011-11-01

On 11/9/11 3:12 AM, Jatinder Mann wrote:
 > It's unfortunate you weren't able to make our TPAC meeting, otherwise  > we could have discussed these issues in person then.

Isn't that why issue responses should clearly go to the mailing list, in general, instead of being buried in meeting notes?  It would have been really nice to have this conversation a month ago, instead of now.  For one thing, you have questions that I have answers to (like what the use cases are and what the benefits are) but you never bothered asking me those questions....

I agree it would have been nice if I'd caught the mention in the meeting notes, but given the number of working groups I have to interact with, reading all the meeting notes in detail is just not feasible, unfortunately.  That's why we have the mailing lists for discussions!

> Per the working group conference call, we felt that iframe visibility, 
> though somewhat interesting, is something to consider in a future 
> revision

I'm fine with that.  That was raised as a question for the working group to consider, not an issue.

>  As for visibility change on navigate away, it wasn't clear what are 
> the benefits would be of changing the state and firing the event when 
> navigating away.

Well, one benefit is that UAs won't claim navigated-away-from documents as "visible", no?  From a developer point of view, that's just weird.

Another would be self-consistency.  The current visibility API spec says:

   If the defaultView of the Document is null, on getting, the hidden
   IDL attribute MUST return true.

The attached testcase shows that in WebKit navigating away from a document sets its defaultView to null.  For navigated-away-from documents, Chrome currently fails the MUST requirement listed above; see the iframe part of the attached testcase.  Is there a test in the test suite for this that it's already failing?

Gecko and Presto currently do not set defaultView to null when a document is navigated away from.  Gecko's implementation currently sets the visibility state to hidden on navigation away from the document and back to visible as needed on navigation back to the document, and fires the requisite events.

I don't have an IE10pp on hand; IE9 throws when trying to get the defaultView for a navigated-away-from document.  There seems to be no provision in the spec for what should happen in that situation.  In a pure JS implementation, the obvious thing to do for visibility API when the defaultView getter throws is to throw, if getting defaultView is part of the algorithm for determining the visibility state.  That seems undesirable to me, and I really doubt IE10pp throws in this situation anyway.

Oh, and if you look at the "remove the subframe" test, IE9 does not null out defaultView in that case.  Gecko nulls it out.  Presto sets it to "undefined".  WebKit nulls it out; once again Chrome fails the MUST requirement above.  Note that the spec does not define what Presto should do here because defaultView is not null.  Is there a test in the test suite for _this_ situation?

Again, I don't have IE10pp on hand.  Does IE10 fire a visibilitychange event on the document that was in the subframe when it was removed from the DOM if the tab is then switched?

In any case, I strongly believe that for purposes of this API consistency in having navigated-away-from or otherwise unloaded documents claim to be hidden would be better than depending on the specifics of defaultView behavior on document navigation and browsing context discard.  This is especially so because the navigation section of HTML5 has not gotten much review yet and the defaultView behavior on navigation may well change from whatever it is right now.  In particular, if I read it right, HTML5 does not clearly define whether documents have a strong reference to their browsing contexts and hence whether some current browsers' behavior of nulling out the defaultView on navigation or browser context discard is acceptable, or indeed whether the defaultView of a navigated-away-from document is even time-invariant.

For purposes of the visibility API specification, I propose that the spec say the following:

   If the Document is not the active document of its browsing context,
   the hidden IDL attribute MUST return true.

or whatever verbiage meshes with the HTML5 terminology du jour.  Similar for the visibilityState attribute.

If we do that, then I feel that firing the visibilitystatechange event is just a corollary of the actual change happening.  We do need to define ordering of that event with unload/pageshow/pagehide, of course. 
  The result will be a much more consistent model for web developers, as well as well as implementors; clearly some implementors were a bit confused by the current spec text and ended up violating MUST requirements as a result.

 > Today, the beforeunload and unload events mark the
> end of a user session to a developer; you can queue saving state off 
> of these events. What additional benefit would this change have?

The ability to write a single codepath if you want to hook visibility changes instead of having to listen to multiple events and manage interactions between them.

We're already using this internally in Gecko, for what it's worth (e.g. 
for canceling vibrations triggered from a document when that document's visibility changes to hidden, including that document being unloaded for any reason).  The programming model is definitely simpler than it would be if multiple events had to be listened to.

> Again, we may want to continue the discussion on the original mail 
> thread - 
> http://lists.w3.org/Archives/Public/public-web-perf/2011Oct/0019.html.

You mean the thread where no one responded a month ago when discussion about this apparently happened?  We could do that, but it looks like we're discussing it here and now instead...  In any case, I care a lot more about actual answers to my concerns than which thread they get posted in.

-Boris

Received on Tuesday, 15 November 2011 18:35:54 UTC