Re: [NavigationTiming] Issues in the document.open test (or perhaps in the spec, if the test is correct)

On 6/20/12 6:56 PM, Karen Anderson (IE) wrote:
> It is my understanding that the document.open test was written to verify the conformance of the processing model step #1: http://w3c-test.org/webperf/specs/NavigationTiming/#processing-model:
>
> 1.If the navigation is aborted for any of the following reasons, abort these steps without changing the attributes in window.performance.timing and window.performance.navigation.
> a.The navigation is aborted due to the sandboxed navigation browsing context flag or the sandboxed top-level navigation browsing context flag, or a preexist attempt to navigate the browsing context.
> b.The navigation is caused by fragment identifiers within the page.
> c.The new resource is to be handled by some sort of inline content.
> d.The new resource is to be handled using a mechanism that does not affect the browsing context.
> e.The user refuses to allow the document to be unloaded.
>
> According to http://www.w3.org/TR/html5/dynamic-markup-insertion.html#dom-document-open, step #9 says "Abort the Document".

Yes, but that doesn't abort the _navigation_.  It aborts the document, 
which is not the same thing.  Not that this spec ever defines 
"navigation", so it's hard to tell whether aborting the document 
constitures "aborting the navigation".  It certainly doesn't abort the 
unload and load steps document.open runs.

Note that even if you think that "Abort the Document" there should imply 
stopping the navigation timing processing model, the setting of 
navigationStart has already happened, in step 7 of the document.open 
steps.  So has the setting of unloadEventStart/End, in step 8.

> The purpose of Navigation Timing is to gather networking timestamps of a document load.

That's fine, but that's informative information, not normative spec text.

> Calling document.open does not initiate a networking request

Neither does loading a data: URI.  So what?  The processing model is not 
defined in terms of networking requests; it's defined in terms of events 
in the webapps page navigation model, and document.open _does_ fire 
those events.

> While you could argue that changing the content of the document should affect the dom* timestamps

I'm not arguing that it _should_.  I'm saying that as the spec is 
written it currently requires it.  That might well be a bug in the spec, 
of course.

> I think our options here are that during a document.open/.write/.close, we would either update all attribute values (those unaffected would have zero deltas) or we don't update any of the values. From the processing model step 1C, it appears we explicitly chose to not change the existing values of window.performance.timing and window.performance.navigation.

I have no idea what 1c is talking about, honestly; it doesn't define 
"some sort of inline content".  If it means document.open, it should say 
that.  At the moment it's a pretty meaningless statement.

> The HTML5 spec states that the document returned from document.open is the same object which invoked the method.  If the object is to remain the same, it doesn't seem to make sense to me to update any of the Navigation Timing timestamps.

That's fine, but the spec then needs to be explicit about it.  Right now 
it's not.

> The test was approved by the group on 2/2/11 (http://www.w3.org/2011/02/02-webperf-minutes.html), almost a year and half ago.  I think the intent of the test is still accurate and adheres with the text in both processing models.

I have no problem with the test per se (and it doesn't matter that much 
when it was approved, honestly; I'm not sure why you're bringing that 
up).  I have a problem with the test not matching the spec, as far as I 
can tell.  It sounds like you think this is due to a bug in the spec. 
Fine.  The spec should get fixed accordingly, then.  I have no opinion 
on that part, though it sounds like Carl-Anton does.

-Boris

Received on Wednesday, 20 June 2012 23:52:55 UTC