- From: James Robinson <jamesr@google.com>
- Date: Mon, 14 May 2012 14:58:15 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: public-web-perf@w3.org
- Message-ID: <CAD73mdLnpz649toaa8DZZ4TbhSrrO8F54uJhVeN=8ABypsX2fw@mail.gmail.com>
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