Timings for beforeUnload event about navigation-timing

[nicjansma]

Yeah... for everyone else's sake, let's quickly review navigationStart:

https://w3c.github.io/navigation-timing/#dom-performancetiming-navigationstart

This attribute must return the time immediately after the user agent finishes prompting to unload the previous document. If there is no previous document, this attribute must return the time the current document is created.

The prompt to unload is when beforeunload is run.

IIRC the original intent was that navigationStart shouldn't begin until the navigation was committed to happening -- and since beforeunload could (technically) cancel the navigation, navigationStart shouldn't happen until after it had the chance to cancel it. So navigationStart is after beforeunload, right before unload is triggered.

This presents the challenge you bring up -- in reality, the user's perception of what happened after the event that triggered the navigation sequence (such as user click) will be affected by long beforeunload handlers. But we probably shouldn't at this point try to redefine navigationStart to be earlier. And if not, since beforeunload happens before navigationStart, it would have a "negative" timestamp in relation to navigationStart (the time origin).

Getting rid of timestamps completely:beforeUnloadDuration? :)

[yoavweiss]

Do we want to expose this data to the next page, or do we want to expose it to the current one?

[andydavies]

Next page for me

1. It's part of the critical path for the next page
2. As many RUM products use beforeUnload to beacon data back, they wouldn't be able to grab the timings

@nicjansma I quite like duration, even though it's a different model to the other timings as not keen on -ve timings

What the timings look like when someone is prompted to cancel the navigation and they take a long time to respond might need a bit of thought.

[yoavweiss]

I'm guessing there will be some privacy/security consideration then for everything cross-origin (e.g. I'm not sure BigSearchEngineCompany.com would want every random site to be able measure what it does at beforeunload)

[cvazac]

I like beforeUnloadDuration, but IMO it's value is lessened if we don't also measure total user "think time" - that is, time spent waiting for the user to dismiss an alert|confirm|prompt.

As for privacy/security, a script inlined in the page can measure these things:
https://gist.github.com/cvazac/4f22883563a334e03365a1c0c478fe92

[toddreifsteck]

Moving to L3 as this is a request for new functionality.

[igrigorik]

As discussed on the last call, unfortunately we cannot expose "duration of beforeunload of the previous" page to the next page. Doing so would leak private data both about the previous page, as well as the user if a prompt is presented. The current definition is specifically crafted to avoid this (as @nicjansma already noted earlier in #79 (comment)) and this behavior is by design.

Closing as a wontfix.

[andydavies]

Not even with a same origin restriction?

[igrigorik]

Same origin pages can already record and report this: instrument beforeunload and use sendBeacon to report the necessary timestamps.

[andydavies]

Don't see how this works - a site can instrument a beforeunload handler it adds but what about the ones 3rd party scripts add?

Currently gathering data on this and will be back when I've got it together