1415630 - PerformanceResourceTiming.fetchStart should mark when FetchEvent is fired on an intercepted channel for now

Status: RESOLVED FIXED

(Core :: DOM: Service Workers, enhancement)

Description

[Ben Kelly [:bkelly, not reviewing]]

When I implemented PerformanceResourceTiming.workerStart I made fetchStart be equal to its value for lack of a better definition.  Talking with Matt Falkenhagen from google we believe it makes sense to probably make fetchStart mark when the FetchEvent is fired on the worker thread.

This is not clearly defined in the spec unfortunately, but it would be worth aligning here for now.  We really need the performance WG spec to align with fetch spec to unambiguously define these values.

Comment 1

[Ben Kelly [:bkelly, not reviewing]]

Attachment: Make PerformanceResourceTiming.fetchStart match the time we dispatch the FetchEvent when SW interception occurs. r=baku

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

Comment on attachment 8926660 [details] [diff] [review]
Make PerformanceResourceTiming.fetchStart match the time we dispatch the FetchEvent when SW interception occurs. r=baku

Review of attachment 8926660 [details] [diff] [review]:
-----------------------------------------------------------------

This patch shifts the value we use for fetchStart when a service worker is involved.  Instead of making fetchStart == workerStart, we make fetchStart == requestStart which we are treating as the time FetchEvent is dispatched.  I tested this manually.  I can't write a WPT that checks this since we have no way to force the service worker to stop in order to observe the time for worker starting up.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b5969c9b92fb
Make PerformanceResourceTiming.fetchStart match the time we dispatch the FetchEvent when SW interception occurs. r=baku

Comment 4

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/b5969c9b92fb