RE: Disparity between time bases in HighResolutionTime and ResourceTiming

I think the best way to approach this issue will be to step back and reiterate through both of the designs.



Current definition: High Resolution Time is measured relative to the start of navigation of the document (performance.navigationStart).

Proposed definition: High Resolution Time is measured relative to the start of navigation of the root document (parent.performance.navigationStart attribute).



Both of these definitions will give the same results when using High Resolution Time within the root document's context. The differences in these definitions is only noticeable when comparing time values in sub-document contexts.



Let's look at an example scenario. Suppose a document has two same-origin iframes, A and B, where a navigation occurred in A 5 milliseconds after the start of navigation of the root document, and B 10 milliseconds after the start of navigation of the root document. Suppose if we measure the exact moment of time 15 milliseconds after the start of navigation of the root document in both the iframes context.

[Description: cid:image005.jpg@01CD86AB.8A5AABA0]

As the first attached figure shows, the current design is such that time is always measured relative to a document's own start of navigation. With the current definition the value of time reported in the following contexts is shown:

-          performance.now() in iframe B:                5.123 ms

-          performance.now() in iframe A:               10.123 ms

-          parent.performance.now() in A or B:      15.123 ms

-          Date.now() in any context:                          134639846051 ms



With the proposed definition, time will always be measured relative to the root document's start of navigation. With the proposed definition the value of time reported in the following contexts is shown:

-          performance.now() in iframe B:                15.123 ms

-          performance.now() in iframe A:               15.123 ms

-          parent.performance.now() in A or B:      15.123 ms

-          Date.now() in any context:                          134639846051 ms



In the current design, you have easy access to both the time measured from the start of navigation of your context and your parents. The proposed change makes it difficult to measure time relative to just the start of your context's start of navigation.



Security

Now suppose for a moment iframe B is cross-origin and iframe A is same-origin. With the proposed definition, iframe B will now know the amount of time since the parent document was created, data which was not available prior. The current definition protects from that leakage by not measuring time relative to the root document's start.



I know we don't want to create new data leakages, so we could update the proposed definition to measure time relative to the root document start of navigation for same-origin documents and relative to its own start of navigation when cross-origin. In this case, the value of time reported in different contexts would be as so:



-          performance.now() in iframe B:                5.123 ms

-          performance.now() in iframe A:               15.123 ms

-          parent.performance.now() in A or B:      15.123 ms

-          Date.now() in any context:                          134639846051 ms



Here the proposed design has an inconsistent behavior between cross-origin iframes and same-origin iframes, which may be confusing to developers. The current design is consistent in that it uses the same origin reference point: start of the context's navigation.



Timing Spec Impact

The impact on the Timing specs is shown in the figure attached. The current definition keeps all timelines independent. If one wants to view the timeline relative to the root document, the sub-documents have already been represented by their Resource Timing data. The proposed definition would push out all iframe timelines to be relative to the root document.



[cid:image003.jpg@01CD86D9.3D1C4320]



Sharing Data Between Sub-Documents

If one wanted to compare High Resolution time stamps between two same-origin iframes, with the current proposal one just needs to call parent.performance.now() and the same time will be reported in all same-origin contexts.



If there are multiple levels of iframes (root has iframe A, iframe A has iframe B, iframe B has iframe C, etc), the proposed model will only allow measuring relative to the start of navigation of the top most document in the hierarchy (root document), which may not be desirable. With the current definition you can walk up the hierarchy to make calls relative to a particular context's start of navigation.



It will be interesting to understand the use cases of wanting to share data between frames. For the case of comparing Timing spec data for sub-documents, the current definition already gives that representation in the root document's Resource Timing (above figure). For the case of synchronizing animations, you would probably measure the deltas in time, not the absolute time (though you can use parent.performance.now() to measure the absolute times).



Also I should add, though we may not want to encourage it, developers can always compare High Resolution Time with Date.now() by just adding performance.navigationStart to the performance.now() call. (In the current definition, they would add their document's performance.navigationStart and with the proposed definition, they would add the parent.performance.navigationStart). This time will only be accurate to the millisecond, but will truly be comparable.



Summary

Since this change mainly impacts sub-documents, thinking about this from an ad developer's point of view makes sense - most ads are in iframes. If the developer is looking at the time the server responded with the ad's document (Navigation Timing 2's responseStart attribute), the developer would expect it to be relative to the document's start, not the root. E.g., if responseStart attribute is 101.123ms, wouldn't you think it took 101.123ms for the response to start? It would seem confusing that the data point actually reflects the time since the root document's start of navigation.



There is no loss in functionality using the current design compared to the proposal (said another way, proposal does not provide any additional functionality), current design does not have the privacy leak issue, and the Performance Timeline looks cleaner.  Additionally, considering we have published the spec in CR with this text and IE10 is shipping with the current behavior, some developers may have already taken a dependency.



My position is that we should not change the current design.



Thanks,

Jatinder