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

On Wed, May 30, 2012 at 10:19 AM, Tony Gentilcore <tonyg@google.com> wrote:
> There's another tradeoff: it's desirable for now() to be comparable to
> the values returned by performance.timing. For instance, a child frame
> calling now() in the load event should get a value similar to
> "performance.timing.loadEventStart -
> performance.timing.navigationStart".
>
> The last two expectations in this test demonstrate:
> http://w3c-test.org/webperf/tests/submission/Google/HighResolutionTime/test_cross_frame_start.html
>
> (A) requires now() to be comparable across frames and (B) requires
> now() to be comparable to the frame's timeline.
>
> The implementation on Chrome's dev channel passes (A), but still has
> the bug that it does this regardless across origins. We totally break
> the use-case in (B). Jatinder, what does IE do here?
>
> A shared timebase per origin and a non-zero navigationStart on
> subframes might just be the best solution.

I like that solution.

That also has the advantage in that it allows doing cross-frame
performance measurements. I.e. you can check when the various steps of
a sub-document load happen in relation to the top-level document load.
This can be useful since often a page which visually looks like one
document, might actually be comprised of several frames.

One very concrete use-case would be seeing when the various stages of
an ad which is loaded in an iframe happen in relation to both each
other, and in relation to the top-level document which the user is
seeing.

/ Jonas

Received on Thursday, 31 May 2012 09:26:17 UTC