Re: Where are instances of PerformanceNavigationTiming created?

On 7/10/14, 11:48 AM, Philippe Le Hegaret wrote:
> On Wed, 2014-07-09 at 21:27 -0400, Boris Zbarsky wrote:
>> When, exactly, are these steps executed?  That doesn't seem to be
>> stated.  Presumably this is meant to hook into the "navigate" algorithm
>> somehow, right?
>
> It is hooked into fetch, like "immediately before a user agent starts
> the fetching process", then current document readiness states.

Is that in the fetch spec?  Because the only instance of that text in 
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming2/Overview.html 
is in step 10 of the processing model, which is obviously after step 2.

> agreed. We could move the creation (or reuse, see later below) of the
> object just before step 21 (dom loading)

That would make sense, yes.

> I read that part and I interpreted as the "primary buffer for
> PerformanceResourceTiming resources"

Sure.  My point is that nothing actually clearly defines which objects 
getEntries and company will return.  It seems to be assumed in the spec 
that for resource timing entries only the ones in the primary buffer 
will be returned, but nothing actually _says_ that.

> It's possible to maintain the PerformanceNavigationTiming object around.

It's possible to do all sorts of things.  The question is what behavior 
this spec requires, if any.  And the answer is that as far as I can tell 
I can implement whatever the heck I want for getEntries and it will not 
obviously violate the spec.

I mean, I can obviously reverse engineer other UAs and implement what 
they did.  Hence https://twitter.com/bz_moz/status/487049670024523776

> The processing model notes:
> [[
> Some user agents maintain the DOM structure of the document in memory

I'm not talking about this case.  I'm talking about the case when the 
old document is discarded.

> The note also implies that the processing model algorithm can reuse the
> PerformanceNavigationTiming object which we don't take into account at
> the moment. If we have to define the lifetime of the object, it would
> probably make sense to tie it to the lifetime of the navigator object.

I'm less interested in lifetimes of objects per se (which are 
nondeterministic in a GC world anyway) and more interested in it being 
possible to implement getEntries just based on the spec text of the 
relevant specs.  Right now it's not possible.

-Boris

Received on Thursday, 10 July 2014 16:19:39 UTC