[whatwg] Timing API proposal for measuring intervals

Boris Zbarsky bzbarsky at MIT.EDU
Thu Jul 7 19:37:46 PDT 2011

On 7/7/11 9:15 PM, James Robinson wrote:
> <bikeshed-topic>
> partial interface Window {
>    readonly attribute double monotonicTime;
> };

This seems like a good idea to me (modulo bikeshedding on the exact 
name; I have no obvious opinions there).  Right now Gecko has some 
places where we actually convert monotonic times to "times that can be 
compared to Date.now()" to pass them to script, and we could stop doing 
that if script had access to the monotonic clock.

There's one possible issue with using a double if implementations don't 
actually return fractional values when they first implement.  We ran 
into it in Gecko when we tried changing Date.now() to return non-integer 
values: it turned out that web code was using the return values of 
Date.now() in contexts where a decimal point was not OK (e.g. as ID 
names in CSS selectors).  As long as implementations commit to returning 
high-precision values here from the start, we can avoid this pitfall, I 
think.  The alternative is to define the time in a smaller unit than 
milliseconds, but that would likely complicate porting existing 
Date-based code.

> I propose that monotonicTime be defined as the number of milliseconds
> elapsed since the window creation.

window creation or window proxy creation?  That is, would loading a new 
page in a subframe reset the monotonicTime for that subframe that the 
parent page sees?

Resetting makes some sense in that pages loaded in the subframe can't 
tell when the subframe was created (which could leak info if those pages 
are not same-origin with the parent).  I assume the parent can't access 
this property cross-origin, so we don't have to worry about it detecting 
loads when the child is cross-origin if we do reset on load....

On the other hand, if the subframe is always same-origin with the 
parent, resetting the clock on navigations is a bit weird from the 
parent's point of view: it sees a monotonicTime that actually decreases 
every so often (goes back to 0).

> I do not believe we can change the meaning of Date.now() in ECMAScript

We certainly can't give it better than ms resolution, given our 
experience above.


More information about the whatwg mailing list