Window's time origin is totally different across browsers. Consider simplifying

[noamr]

Currently timeOrigin for window environments is specified as being right before the beforeunload events, or right after confirmation of the unload. However, implementations don't follow this at all!

• In Chromium, navigation start is right after the beforeunload event is handled regardless of prompts
• In WebKit, navigation start is the start time of the navigation's fetch
• In Gecko, navigation start is before the beforeunload event even in the case of prompt (see https://bugzilla.mozilla.org/show_bug.cgi?id=1760010)

This can lead to confusion and for totally different numbers across websites and between browsers (especially Firefox).
Suggesting to simplify the spec to use WebKit's approach, essentially navigation start time = underlying resource fetch start time = 0 (the time origin)

[annevk]

I agree that this would be a step in the right direction. w3c/navigation-timing#160 (comment) (by you!) has notes on potentially making it even better. (I say potentially, as perhaps WebKit already uses the start time of the latest fetch.)

cc @yoavweiss @sefeng211 @achristensen07

[noamr]

I agree that this would be a step in the right direction. w3c/navigation-timing#160 (comment) (by you!) has notes on potentially making it even better. (I say potentially, as perhaps WebKit already uses the start time of the latest fetch.)

Yea, that would be better IMO but more "breaking" in case of a navigation that starts with a cross-origin redirect.

[achristensen07]

I certainly wouldn't oppose putting WebKit's current behavior into the spec as a less shocking change for some browsers on our way to solving navigation-timing issue 160

[domenic]

Who is the right person on the Chromium or Gecko sides to make the call here?

[noamr]

Who is the right person on the Chromium or Gecko sides to make the call here?

@sefeng211 @yoavweiss

[yoavweiss]

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1316609
Chromium can most probably align with WebKit's definition, but we'd need to verify that won't result in too big of a disruption in practice before that happens.

[sefeng211]

We are onboard about changes and will use https://bugzilla.mozilla.org/show_bug.cgi?id=1760010 to make the change. We'll also verify the results to make sure there's no big shift in the data.

[noamr]

I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1316609 Chromium can most probably align with WebKit's definition, but we'd need to verify that won't result in too big of a disruption in practice before that happens.

Pages that would have a disruption would have a navigationEntry.startTime > 0 today, which is maybe easy-ish to probe?