- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 10 Jul 2014 12:19:11 -0400
- To: Philippe Le Hegaret <plh@w3.org>, Arvind Jain <arvind@google.com>
- CC: "public-web-perf@w3.org" <public-web-perf@w3.org>
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