Re: Where are instances of PerformanceNavigationTiming created?

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.

> There's a bit of a problem here, in that this processing model seems to 
> envision creation of a PerformanceNavigationTiming object before the 
> page that results from the navigation exists, but this object, like all 
> other IDL objects, can't be created before the corresponding JS global 
> is created.  What's probably needed here is some sort of record that's 
> created at navigation start and stores values like the unload time, etc, 
> with the values then copied to a PerformanceNavigationTiming once the 
> latter can be created... or something along those lines.

agreed. We could move the creation (or reuse, see later below) of the
object just before step 21 (dom loading) and copied the values at that
stage.

Arvind, what do you think?

> > We don't explicitly say when performance.getEntriesByType would be able
> > to return the instance however but I believe the expectation would be
> > from the beginning, ie as soon as the page is able to invoke
> > getEntriesByType.
> 
> Well, so...  The spec text in 
> http://www.w3.org/TR/performance-timeline/#sec-performance-timeline is 
> fairly vague but implies that PerformanceEntry instances should be 
> gettable via getEntriesByType as long as they exist.  Or perhaps 
> forever?  There is no mention in 
> http://www.w3.org/TR/performance-timeline/#sec-window.performance-attribute 
> of them being able to stop existing...
>
> However, the processing model of 
> https://w3c.github.io/web-performance/specs/ResourceTiming/Overview.html#processing-model 
> certainly assumes that PerformanceEntry instances can stop existing.  In 
> fact I _think_ it assumes that only entries that are stored in the 
> "primary buffer" actually exist and can be fetched vie getEntries and 
> company.
> 
> It would be good to get all this actually clearly defined.

I read that part and I interpreted as the "primary buffer for
PerformanceResourceTiming resources", because I don't think we meant to
have the PerformanceNavigationTiming object counted as part of the
buffer limit (the event is named resourcetimingbufferfull after all).

We don't have or need a buffer for PerformanceNavigationTiming objects
since there is only one per browsing context.

> For example, if I navigate away from a window, or close it, but hold a 
> reference to the performance object, can I still get its 
> PerformanceNavigationTiming?  Why or why not?

It's possible to maintain the PerformanceNavigationTiming object around.
The processing model notes:
[[
Some user agents maintain the DOM structure of the document in memory
during navigation operations such as forward and backward. In those
cases, the PerformanceNavigationTiming object must not be altered during
the navigation.
]]
https://w3c.github.io/web-performance/specs/NavigationTiming2/Overview.html#processing-model

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.

Philippe

Received on Thursday, 10 July 2014 15:48:29 UTC