RE: Disparity between time bases in HighResolutionTime and ResourceTiming

All Resource Timing attributes are defined as type DOMHighResTimeStamp. The High Resolution Time spec defines the DOMHighResTimeStamp as a type "used to store a time value measured relative to the navigationStart attribute of the PerformanceTiming interface [NavigationTiming], the start of navigation of the document, or a time value that represents a duration between two DOMHighResTimeStamps."

We had updated the definition of performance.now() and DOMHighResTimeStamp to be relative to the start of navigation of the document, not the root document, based on this discussion: http://lists.w3.org/Archives/Public/public-web-perf/2012Jun/0000.html. Essentially, this design doesn't have the privacy leak issues and still allows comparing time with iframes by converting back to the unix epoch time base by adding performance.navigationStart to any DOMHighResTimeStamp value. We should not change this design for either High Resolution Time or the Timing specs.

The sentence you are referring to is from Section 5.2 Monotonic Clock in Resource Timing - "For all resources, including subdocument resources, the user agent must record the system clock at the beginning of the root document navigation and define subsequent timing attributes in terms of a monotonic clock measuring time elapsed from the beginning of the navigation." The reference to "root document" in that section refers to the internal UA implementation of the monotonic clock.

The internal implementation note was written to avoid a particular bug. Suppose you have a Site A that loads an IFrame B thirty seconds after its start of navigation and a user changes the system clock time before the IFrame loads (say at time 15 seconds relative to Site A's navigationStart). In this case, because all of the time values are DOMHighResTimeStamps, there will be no impact of this change to the individual timelines of Site A or IFrame B - each resources in the two timelines will be placed relative to time zero (equal to the document's navigationStart) and the IFrame B will be represented in Site A's timeline as a resource. However, if you convert both of these timelines to unix epoch by adding each document's performance.navigationStart, the unix epoch time for IFrame B will be impacted by the clock change. With the text to ensure that 'user agent records the system clock at the beginning of the root document and defines subsequent timing attributes in terms of a monotonic clock', this issue will not occur.

I personally think that this text should be removed from Resource Timing and instead be written in Performance Timeline, as the same issue would impact any Timing spec. I will take that action.

Jatinder


From: simonjam@google.com [mailto:simonjam@google.com] On Behalf Of James Simonsen
Sent: Wednesday, August 8, 2012 4:42 PM
To: public-web-perf
Subject: Disparity between time bases in HighResolutionTime and ResourceTiming

Resource Timing says:

"...the user agent must record the system clock at the beginning of the root document navigation..."

High Resolution Time says:

"...the number of milliseconds from the navigationStart attribute of the PerformanceTiming interface, the start of navigation of the document..."

So in iframes, Resource Timing will be offset, but now() won't be. That seems bad. We should be consistent.

We went with the root document in Resource Timing intentionally. We want to present a uniform timeline that can just be displayed, including iframe content.

So I think we should change High Res Time to match Resource Timing's definition.

We should define "root document" too. I think we can work the cross-origin concerns into that: walk the parent document chain as long as there's a parent and it has the same origin as the current document. Wherever you stop is the root document.

James