Re: Firefox and User Timing API in workers

On Fri, May 22, 2015 at 10:24 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> https://w3c.github.io/resource-timing/#terminology clearly says:
>
>   Throughout this work, all time values are measured in milliseconds
>   since the start of navigation of the document. For example, the
>   start of navigation of the document occurs at time 0. The term
>   current time refers to the number of milliseconds since the start
>   of navigation of the document until the current moment in time.
>
> What exactly does "the start of navigation of the document" mean in
> workers?  That's the only thing here that actually needs serious
> standardization work, by the way: exposing interfaces is easy; it's making
> them behave the same way in different UAs that's the interesting part that
> requires a standard.


Ah, good catch, missed that in the earlier update. Opened a bug to track
this:
https://github.com/w3c/resource-timing/issues/23


>      3. navigationStart is taken from the window PerformanceTiming object
>>     when the worker is created.
>>     For window-less workers (SharedWorkers, ServiceWorkers)
>>     navigationStart is the creation time of the worker itself.
>>
>> Note that we've recently added workerStart to RT:
>> https://github.com/w3c/resource-timing/pull/18
>>
>
> That's not the same thing.  First of all, the workerStart that was added
> is ServiceWorker-specific (and hence should probably have a name that
> reflects that, by the way).
>

Right, as written its SW specific.. I think we can make it work in both
cases though.


> But more importantly, the navigationStart we are adding is the time which
> is used as the zero time for performance.now() in workers, and that's not
> at all the same thing as the time when the worker was started.


FWIW, there is no "navigationStart" attribute in RT. The intent was to have
"workerStart" reflect the "zero time" within a worker.


> P.S.  Two more notes on the state of exposing things in workers:
>
> 1)  I don't believe anything exposes the Performance interface in workers,
> so exposing PerformanceResourceTiming in workers is not that useful, since
> nothing per spec allows you to get your hands on one, afaict.  This is
> clearly a bug in the spec.
>
> 2)  PerformanceResourceTiming inherits from PerformanceEntry, but
> PerformanceEntry is not exposed in workers.  Web IDL doesn't mean to allow
> an interface being exposed where its inherited interfaces are not exposed
> (though currently it does, by accident; this oversight will be corrected).
> PerformanceEntry needs to be exposed in workers as well for all this to
> work.
>

I do believe that latest draft of Perf Timeline should address both of the
above:
- http://w3c.github.io/performance-timeline/#the-performance-interface
- http://w3c.github.io/performance-timeline/#the-performanceentry-interface

ig