Re: [PerformanceTimeline] Unclear what getEntries and company return

On Wed, Aug 21, 2013 at 7:41 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> This is implementation feedback for Performance Timeline and Resource
> Timing.
>
> It's not clear to me, as an implementor, exactly what getEntries is
> supposed to return, in two ways:
>
> 1)  It's not clear whether PerformanceResourceTiming entries for loads
> that are still in-progress are returned from this method.
>
> The normative text for getEntries is rather sparse:
>
>   The getEntries method returns a PerformanceEntryList object that
>   contains a copy of all PerformanceEntry objects in chronological
>   order with respect to startTime.
>
> At the same time, Resource Timing, for example, has a "primary buffer"
> that can fill up.  Once it's full new PerformanceResourceTiming objets are
> not added to that primary buffer.  Would those still be returned from
> getEntries()?  Or does getEntries only return PerformanceResourceTiming
> that are in the primary buffer?
>

The latter. We should clear this up.


> This ambiguity seems like a hard blocker to actually proceeding with our
> implementation.
>
> 2)  It's not quite clear to me what the "contains a copy" language means.
>  Does this mean that this predicate:
>
>   performance.getEntries()[0] == performance.getEntries()[0]
>
> tests false if getEntries returns a nonempty list?  That is, each time the
> list is returned it has to contain brand-new objects?  If this is in fact
> the intent, it's rather surprising; given that the objects only have
> readonly properties it seems like it would be better to return existing
> objects.  If we _do_ want to return brand-new objects every time, it seems
> like we should simply return dictionaries instead: then we get the
> new-object behavior for free and script gets non-magical objects to work
> with.


Blink doesn't create copies. It'd be silly to. I think we should just
update the spec.

James