- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Sat, 23 May 2015 01:24:05 -0400
- To: public-web-perf@w3.org
On 5/22/15 4:54 PM, Ilya Grigorik wrote:
> We've recently updated Resource Timing [1] to be exposed to Workers
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.
> 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).
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. Simple testcase that shows that for dedicated workers the
worker start time and the zero time for performance.now() in a worker
are different in actual shipping implementations:
<script>
var workerData = "postMessage(performance.now())";
var workerURL = URL.createObjectURL(new Blob([workerData]));
setTimeout(function() {
var w = new Worker(workerURL);
w.onmessage = function(e) { alert(e.data); };
}, 2000);
</script>
Note that this is also the zero time that needs to be defined for
resource timing, presumably....
We named this navigationStart because that's what the zero time is named
in windows and there is value in being able to write code that runs in
both Window and Worker without worrying about things being named
differently. The other option is to add yet another attribute somewhere
off of Performance or some object hanging off it that returns the zero
time in all globals where Performance is exposed.
-Boris
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.
Received on Saturday, 23 May 2015 05:24:35 UTC