Bug 174862 – Performance API: Implement performance.timeOrigin

• Component: Platform
• Status: RESOLVED FIXED

[Nicolas]

Latest editor draft: https://w3c.github.io/hr-time/

HR-Time-3 introduced this attribute, which is useful for developers to be able to compare timings of entries sourced from different time origins (like windows or workers).

It has already been implemented in Firefox, Edge has it in Preview, and will also be shipped by Chrome[1].

[1] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ck9M6Ev21lo

[Radar WebKit Bug Importer]

<rdar://problem/33575468>

[Alex Christensen]

Created attachment 430926 [details]
patch

[Ryosuke Niwa]

Comment on attachment 430926 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=430926&action=review

> Source/WebCore/page/Performance.h:78
> +    DOMHighResTimeStamp timeOrigin() const;

Is this time origin varied across origins?
Otherwise, it can create cross-origin tracking vector, right?

[Alex Christensen]

Comment on attachment 430926 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=430926&action=review

>> Source/WebCore/page/Performance.h:78
>> +    DOMHighResTimeStamp timeOrigin() const;
> 
> Is this time origin varied across origins?
> Otherwise, it can create cross-origin tracking vector, right?

This time stamp is in milliseconds since 1970, so it doesn't identify the user that way.
The value is from the time the DocumentLoader started loading the Document (seen in DOMWindow::performance) or the time that the Worker was created (seen in WorkerGlobalScope::WorkerGlobalScope) which should not lead to a tracking vector.  This value is already indirectly exposed through Performance::now, which is the number of milliseconds since this time.
I'm hoping this is covered by tests.  Waiting on EWS.  If it isn't, I'll write some.

[Alex Christensen]

Created attachment 430935 [details]
Patch

[Alex Christensen]

http://trac.webkit.org/r278665