The two quotes about timing don't quite seem to match, one says to use milliseconds, the other to use milliseconds or finer, but no words on how finer could be achieved. I suggest the two quotes are moved to the same place in the document and aligned. Since "otherwise specified" never happens, I further suggest to remove that particular moderation. "Unless otherwise specified, in rest of this work, time is measured in milliseconds since midnight of January 1, 1970 (UTC)." "The accuracy of the timing-related attributes in the PerformanceTiming interfaces is recommended to be one millisecond or finer." All we actually need is to say "Throughout this work, time is measured in milliseconds since midnight of January 1, 1970 (UTC)."
Section 4.2 uses (mostly) secureConnectionStart, while 4.5 uses exclusively handshakeStart (algorithm and diagram).
The note on relaxed same origin policy doesn't have any obvious relevance to the place in the document. I suggest it be moved to the security section, and a short summary of our discussions and decisions presented there.
In the security section, section 6.3 needs a little bit more flesh. It currently says "There is potential for [badness] by using carefully crafted timing attacks.", which is not very enlightening. I suggest a sentence or two is included about how one would go about such an attack, so that it becomes clear why cross-origin restrictions are the answer.
The spec has[Supplemental] interface Window { attribute Performance performance; };but as plh pointed out, [Supplemental] is not (yet) defined in Web IDL. I would recommend writing this as:[NoInterfaceObject] interface WindowPerformance { readonly attribute Performance performance; }; Window implements WindowPerformance;
Minor nit, "For example, the following Javascript shows the time it take to fully load a page: " That is not quite true. If the first package from the server happens to contain only "", the script is just measuring some random part of the page load. The explanation clarifies that, but still, saying "shows the time it take to fully load a page" is just misleading.
"This interface does not include an attribute to represent the completion of sending the request, e.g., requestEnd. Completion of sending the request from the user agent does not always indicate the corresponding completion time in the network transport, which brings most of the benefit of having such an attribute. Some user agents have high cost to determine the actual completion time of sending the request due to the HTTP layer encapsulation. " These sound partially like implementation issues. Why is some implementation issue affecting a spec this way? Could requestEnd, even if just the user agent part of it - not network layer, be still useful for POST?
"TYPE_RESERVED: Any navigation types not defined by values above." Since types are quite limited and underspecified, all the script initiated loads would be TYPE_RESERVED. So would all the form submissions. Is that what is really wanted? Seems like at least Chrome uses TYPE_NAVIGATE also for other things than just "navigation started by clicking on a link or entering the URL in the user agent's address bar." But in which all cases it uses that type, I dunno. And what does IE9 do?
"Client-side redirects, such as those using the Refresh pragma directive, are not considered HTTP redirects or equivalent by this spec. In those cases, the type attribute should return appropriate value, such as TYPE_NAVIGATE, as if in non-redirect navigation." This is too vague. It must be specified when to use TYPE_NAVIGATE and when perhaps TYPE_RELOAD and when something else. Using TYPE_NAVIGATE would actually violate its current definition "navigation started by clicking on a link or entering the URL in the user agent's address bar."
"Some user agents maintain the DOM structure of the document in memory during navigation operations such as forward and backward. In those cases, the window.performance.timing and window.performance.navigation objects must not be altered during the navigation."What does this actually mean?
I still don't quite understand why one kind of navigation (navigation from a page to another page in bfcache) shouldn't alter the .performance.* objects. But if others think that is the behavior we want, that is ok to me.
I wonder why there is window.performance.timing (which is a very generic name), and not just window.performance.navigation which could contain all the information?
I just noticed that the navigation timing API is defined in terms of wall-clock epoch times. Unfortunately, such times on modern computer system have an unpleasant property: they are not monotonically increasing at the rate time actually passes at.
MSIE defines window.performance.toJSON. Should we?
Since this will be a long lived spec, I think the timing unit should be nanoseconds rather than milliseconds. With long long there is still plenty of range using nanos, and the extra precision will be needed as computers get faster.
In the case of dynamic markup insertion, I agree with Karen that it is confusing to update some of the attributes and not the others, particularly because the timeline implies an ordering. Our options appear to either not allow dynamic markup insertion to change the Navigation Timing attributes or in the dynamic markup insertion case, to update all attributes, including zero deltas for attributes that are not changed.It appears that the spec authors attempted to capture the former, though the spec text is not very clear. I recommend we fix the spec bug to make the intended behavior more clear.
So none of these [implementations] do what the spec calls for, which is good because what the spec calls for makes no sense to me.
"the timing attribute" returns a PerformanceTiming object. There are not such objects "in" this attribute, that I can see. So I'm not sure what's being sorted here, nor what "chronological order of the corresponding browsing context" means exactly. This needs to be clarified, assuming this sentence is needed at all.
I doubt that it actually matters that the saving is done "in memory" as opposed to "on disk" or "in the cloud"...
One of the current challenges is understanding how much latency is introduced by the delay involved in waking the radio in wireless devices from power saving modes.My guess is that the information required to create a radioAwake attribute as part of Navigation (and Resource Timing) isn't exposed to the browser but would be interested in other thoughts and comments.