[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.
-Boris
More information about the whatwg
mailing list