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

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

The purpose of Navigation Timing is to gather networking timestamps of a document load.  Calling document.open does not initiate a networking request and instead opens an input stream for writing.  While you could argue that changing the content of the document should affect the dom* timestamps, it would be very odd to update these timestamps and not the others.  E.g., it may be confusing to see navigationStart occur in some cases after fetchStart. Further, updating any of the timestamps after document.close would then lose the original timestamps of the true document load.  I don't think that this would be desirable.  Getting timing data for these markup updates is easily accomplishable using onreadystatechange events.

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.

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

Is there a use case that this behavior breaks or a scenario that cannot be properly timed?

Thanks,
Karen

-----Original Message-----
From: Carl-Anton Ingmarsson [mailto:carlantoni@opera.com] 
Sent: Wednesday, June 13, 2012 3:38 AM
To: Boris Zbarsky
Cc: public-web-perf@w3.org
Subject: Re: [NavigationTiming] Issues in the document.open test (or perhaps in the spec, if the test is correct)

> 
> So as far as I can tell, calling document.open and then document.close 
> should affect various navigation timing values (navigationStart, 
> domLoading, domComplete, loadEventStart, loadEventEnd, etc).  This is 
> what Gecko does.

It's also my understanding that document.open() document.close() should affect all the non-network related attributes, e.g.

Should change: navigationStart, unloadEventStart, unloadEventEnd,
               domLoading, domInteractive,
               domContentLoadedEventStart, domContentLoadedEventEnd,
               domComplete, loadEventStart, loadEventEnd.

Should not change: redirectStart, redirectEnd, fetchStart,
                   domainLookupStart, domainLookupEnd,
                   connectStart, connectEnd,
                   secureConnectionStart, requestStart,
                   responseStart, responseEnd.

This of course means that navigationStart, unloadEventStart and unloadEventEnd now can have values greater than the unchanged attributes. Perhaps it's better to set all the unchanged attributes (except redirect[Start|End]) to be the same as unloadEventEnd or domLoading?

The tests expectation that all of the attributes should stay the same is in my opinion completely wrong. I'd expect to be able to get timing data of documents I create with document.open() document.close().

- Carl-Anton

Received on Wednesday, 20 June 2012 22:57:19 UTC