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