Re: Firefox and User Timing API in workers

On Wed, May 27, 2015 at 11:53 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
>
> Right, as written its SW specific.. I think we can make it work in both
>> cases though.
>>
>
> Can we just have a property that works in all cases (workers, windows,
> etc) so people can just write their code without worrying about where it's
> running.


That's what I meant to say.. Single attribute that works across all worker
cases :)


> The intent was to have "workerStart" reflect the "zero time" within a
>> worker.
>>
>
> Given that the zero time within a dedicated workers is the zero time of
> its parent page, calling it "workerStart" is pretty odd.


We landed a change back in February that updated its definition to: "The
time origin for dedicated and shared workers must be equal to the time of
creation of the worker context". From memory, the rationale was:

- a worker may not have have a "parent document" - e.g. a worker spawned to
do a background update or process a notification
- a worker can spawn own worker
- the difference between shared vs dedicated was confusing
- if you need to communicate some timestamp of parent context you can still
do so

Additional context:
- https://github.com/w3c/hr-time/issues/1
- https://lists.w3.org/Archives/Public/public-web-perf/2015Mar/0004.html

On Wed, May 27, 2015 at 2:00 PM, Andrea Marchesini <amarchesini@mozilla.com>
wrote:

> Note that we use navigationStart in workers for performance.now(). Do you
> handle this in the spec?
>

As currently specced in http://w3c.github.io/hr-time/:

> The now method MUST return a DOMHighResTimeStamp representing the time in
milliseconds from the time origin to the occurrence of the call to the now
method.
>
> The time origin is the time value from which time is measured.
> - The time origin must be equal to the time of the start of navigation of
the current document.
> - The time origin for dedicated and shared workers must be equal to the
time of creation of the worker context.

ig