As soon as the spec is updated, I'll do the changes in gecko. To me it's important to have a starting time for Workers and navigationStart was a reasonable value, but I'm happy to use workerStart. We just landed the code in m-i and it's already in the nightly builds. But if the spec is quickly updated, I can provide a fix before the next cycle. Note that we use navigationStart in workers for performance.now(). Do you handle this in the spec? b On Wed, May 27, 2015 at 7:50 PM, Ilya Grigorik <igrigorik@google.com> wrote: > > On Mon, May 25, 2015 at 4:13 AM, Andrea Marchesini < > amarchesini@mozilla.com> wrote: > >> 2. PerformanceTiming is not exposed to workers. The only attribute that >>>> can be used as marker name is 'navigationStart'. >>>> >>> >>> Not sure I follow this. Why are the marker names restricted? Is this >>> related to: https://github.com/w3c/user-timing/issues/1 -- ? >>> >> >> It's about this "The *startMark* and *endMark* arguments may be the name >> of one of the attributes in the PerformanceTiming >> <http://www.w3.org/TR/navigation-timing/#performancetiming> interface [Navigation >> Timing] <http://www.w3.org/TR/user-timing/#NavigationTiming>. In this >> case, the value of that attribute is used as the DOMHighResTimeStamp >> <http://www.w3.org/TR/hr-time/#domhighrestimestamp> time value." >> In workers we don't expose the all PerformanceTiming interface so this >> point is not fully implemented. We just support 'navigationStart'. >> > > Ah, ok, with you now. User Timing spec is out of sync.. > - PerformanceTiming -> PerformanceNavigationTiming > - PerformanceNavigationTiming is not exposed in worker (only Resource > Timing is).. I don't think that section should apply at all for UT within > worker; navigationStart shouldn't be exposed either.. we should clarify > this in the spec. > > ig >
Received on Wednesday, 27 May 2015 21:00:56 UTC