Re: Where are instances of PerformanceNavigationTiming created?

On 7/10/14, 2:36 PM, Philippe Le Hegaret wrote:
> I'm wondering how far we need to go along that path however. For
> example, we never indicated when the initial window.performance object
> gets created.

Generally speaking, such things should in fact be specified.  ES6 
specifies this sort of thing for its objects (all the built-in ones are 
created when the global is created, for example), and the HTML spec 
specifies things like window.document.

In you case, you want window.performance to be created when the window 
is, presumably.

It turns out that in practice it's not observable when browsers create 
the object as long as they create it before returning from the getter 
for the "performance" property and as long as they put the right data in 
it when creating it.

> So far, it's assumed to be there as soon as a script can
> be executed, ie by dom loading, like several objects available from
> window.

Assumed by whom?  Again, some specs define this explicitly for their 
objects, and that's generally a good idea.  Just like specs should 
define which global their objects are associated with...

> It seems to me that we need to define this in performance timeline. In
> others words, each specification (like Navigation or Resource Timing)
> should define when the objects get created and added to the entries
> list

Right now, note, there isn't even an "entries list" for things to get 
added to (and hence nothing gets added to it, of course).

> In that case, we would need to add the
> following to Performance Timeline:
> [[
> A part of the steps defined in "unload a document" [See Unloading
> documents, HTML], if both the Document's salvageable state and recycle
> are false, the Document's browsing context must discard all instances of
> PerformanceEntry objects after discarding the Document and getEntries()
> must return an empty PerformanceEntryList.
> ]]

That's the general idea, but instead of monkeypatching please use the 
existing extensibility point the HTML spec has for this.  See 
which is invoked by step 11 of 
-- that's the right place to hook into.  That's assuming you want to 
clear things on unload, of course.  And you'll want to define "discard": 
all it means is it's gone from whatever getEntries looks at, right?


Received on Thursday, 10 July 2014 19:10:01 UTC