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

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.