W3C home > Mailing lists > Public > public-web-perf@w3.org > May 2012

Re: [HighResolutionTime] performance.now() value depends on the document, which can cause problems

From: James Robinson <jamesr@google.com>
Date: Mon, 14 May 2012 14:58:15 -0700
Message-ID: <CAD73mdLnpz649toaa8DZZ4TbhSrrO8F54uJhVeN=8ABypsX2fw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-web-perf@w3.org
On Mon, May 14, 2012 at 11:07 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> Right now, the value returned by performance.now() depends on the Window
> the performance object came from.  This means that any code working with
> multiple subframes and trying to use performance.now() has to be extremely
> careful: the value will differ in different subframes depending on when
> they were last loaded.  This behavior has already bitten the editor of the
> requestAnimationFrame spec, and I expect it to bite web authors.
> The bad news is that I'm not sure how to fix this problem.  :(  One option
> is to walk up the window.parent chain as long as the ancestors are
> same-origin, but that would make the .now() method a lot slower...

I agree this is a problem.  It's really crazy for people to try to keep
track of which window they are in and as you mention this bit me (although
I had thought about it, then forgot about it again).

I like the idea that same-origin frames share a timebase, but I don't think
walking window.parent is sufficient.  You could have sibling iframes that
are the same origin as each other and are scripting each other but
different origin from their parent.  I think this proposal really boils
down to keeping a timebase for each unique origin within a top-level
browsing context.

I'm not too worried about the performance hit - we can make this fast in
the browser.  There aren't that many unique origins within a top-level
browsing context and getting the origin has to be fast to make other JS
accessors fast.  If authors are doing this in JS it's less likely to be as
reliable or fast as if we do it.

- James

> -Boris
Received on Monday, 14 May 2012 21:58:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:04:32 UTC