Report Critical-CH caused restart in NavigationTiming

[arichiv]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Report Critical-CH caused restart in NavigationTiming
• Specification or proposal URL (if available): Add criticalCHRestart w3c/navigation-timing#188
• WebKit Request for Position: Report Critical-CH caused restart in NavigationTiming WebKit/standards-positions#156
• Chromoium Intent to Ship: https://groups.google.com/a/chromium.org/g/blink-dev/c/f28WWMD8HVE
• Chromium Feature: https://chromestatus.com/feature/5140317616996352
• Chromium Issue: https://crbug.com/1425910
• Tag Review: FYI only [FYI] Report Critical-CH caused restart in NavigationTiming w3ctag/design-reviews#833

Other information

Websites can indicate that a particular Client Hint is critical to the page by including it in a Critical-CH HTTP response header. Doing so will trigger a connection restart if the hint listed in the Critical-CH HTTP response header could be (but wasn’t) included in the HTTP request initially sent. We should indicate this has happened in Navigation Timing so that developers can know if a restart occurred and impacted timing.

[zcorpan]

cc @sefeng211

[sefeng211]

So we've resolved UA Client Hints as neutral, I don't know if we can say anything above neutral here.

Secondly, UA Client Hints a WICG feature which is only implemented one agent, and we are asked for adding something particular about it into a feature that is included in the WebPerf charter. Is it okay @zcorpan ?

@arichiv As Noam mentioned in w3c/navigation-timing#188, It'd be handy to know where this value sets. Another question is, for the reconnection, what happens to the other timing values of the entry? Do they all get updated based on the new connection?

[arichiv]

1. Neutral works
2. https://wicg.github.io/client-hints-infrastructure/#navigation-response, likely as a replacement for the "has reloaded for Critical-CH" concept.
3. The existing time stamps up to requestStart should be retained, then this timestamp should serve as a sort of second 'requestStart', and the remainder of the time stamps (starting with responseStart) will continue after. @yoavweiss if I'm missing anything

[zcorpan]

If the reloading mechanism is implemented then it seems OK to expose the reload timestamp to the page. I don't think there are privacy concerns since the cause for reload isn't a property of the user or the device per se, but the server. In principle, the server could change the response to tell the client that reload happened.

Suggested position: neutral.