In workers, mark names can be PerformanceTiming attributes but they cannot be retrieved in measures

[mcomella]

In workers (and other non-Window global objects), we can call performance.mark named with a PerformanceTiming attribute but we cannot access those marks in performance.measure because it will throw, e.g.:

// worker.js
performance.mark('navigationStart'); // no error
performance.measure('failure', 'navigationStart'); // throws an Exception

This makes the mark less useful and it's easy to cause an exception and stop the script with it. I find it unintuitively inconsistent with Window global objects which don't let you create performance marks with these names.

I think that the behavior in non-Window global objects should either be:

1. the user cannot create a PerformanceMark with a PerformanceTiming attribute markName (i.e. the same as Window global objects)
2. the user can call performance.measure with PerformanceTiming attributes without throwing an error (i.e. no restrictions around using PerformanceTiming attributes as markNames in non-Window global objects)

Test case

testcase.tar.gz

Run with, e.g.tar -xf testcase.tar.gz && cd testcase && python3 -m http.server, opening localhost:8000/testcase.html in the browser, and opening the browser console.

Spec references

3.2.1 The PerformanceMark Constructor allows you to create a PerformanceMark whose markName is an attribute in PerformanceTiming if the global object is not a Window (e.g. a worker).

This behavior that causes performance.measure to throw is defined in 4.2 Convert a name to a timestamp – throw an error if the global object is not a Window, which is called by 4.1 Convert a mark to a timestamp, which is called by 3.1.3 measure() method.

[yoavweiss]

Makes sense to not have those "special names" apply to workers. A broader question: are the special names useful in the Window context? They are definitely adding a bunch of overhead..

/cc @nicjansma @mmocny @anniesullie

[paulirish]

A broader question: are the special names useful in the Window context? They are definitely adding a bunch of overhead..

As a user, I don't like the 'navigationStart' name, especially as it's a shorthand for 0, which is now very straightforward in L3. Turns out I also chimed in on this topic a few years back: #44 and said

Also: I know the L1 spec provided the hack of using 'navigationStart' as a string, and that the WG is interested in removing that approach.

Using provided start/end times (from L3) is so superior to passing this magic string or the awkward undefined argument.

[yoavweiss]

Well, turns out we added a use counter for it, and it's close to 3% of page views.

So I guess these "special names" are not going anywhere anytime soon. But we can make sure it's not there for workers.