service-workers/navigation-timing-extended.https.html: strict comparisons between coarsened timestamps of back-to-back steps #64636

service-workers/service-worker/navigation-timing-extended.https.html compares coarsened timestamps of back-to-back spec steps with strict assert_greater_than, so an implementation that follows the steps produces equal values whenever both marks fall in one coarsening interval - which is the usual case.

Assertion 3 - assert_greater_than(timingFromWorker.handleFetchEvent, timingFromEntry.fetchStart, 'fetchStart should be marked before the Fetch event handler is called'):

• Under a service worker, Navigation Timing's fetchStart is the service worker timing's fetch event dispatch time.
• Service Workers' Create Fetch Event and Dispatch sets that time at step 17.4.12 and dispatches the event at 17.4.13; handleFetchEvent is the listener's first statement.
• The spec puts nothing between the two marks, and HR-Time coarsens both (at least 100 µs; 1 ms in Firefox and Safari). So the two readings are often equal, and equal satisfies the order the spec defines.

Assertion 2 - assert_greater_than(timingFromEntry.fetchStart, timingFromWorker.activateWorkerEnd, ...) - has the same shape. activateWorkerEnd is taken in the activate handler's waitUntil reaction; between it and step 17.4.12 there is only the state change, Run Service Worker and one queued task.

Measured in an engine that follows these steps (125 µs coarsening):

• assertion 3 failed in 7 of 20 runs, every time with equal values;
• in 163 of 180 navigations to an active worker, handleFetchEvent - fetchStart was 0 coarse ticks (17 were 1 tick, none more);
• in 4 of 36 navigations that waited for activation, fetchStart == activateWorkerEnd.

No browser passes the file today, and each fails a different assertion (wpt.fyi): Chrome fails assertion 1, Firefox fails assertion 3 (fetchStart after the handler), Safari fails assertion 2.

Suggested fix: use assert_greater_than_equal for assertions 2 and 3. Assertion 1 can stay strict, since the test's worker delays activation by 500 ms (DELAY_ACTIVATION) between workerStart and activateWorkerEnd.