-
Notifications
You must be signed in to change notification settings - Fork 30
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Timings for beforeUnload event #79
Comments
Yeah... for everyone else's sake, let's quickly review https://w3c.github.io/navigation-timing/#dom-performancetiming-navigationstart
The prompt to unload is when IIRC the original intent was that 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 Getting rid of timestamps completely: |
Do we want to expose this data to the next page, or do we want to expose it to the current one? |
Next page for me
@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. |
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) |
I like As for privacy/security, a script inlined in the page can measure these things: |
Moving to L3 as this is a request for new functionality. |
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. |
Not even with a same origin restriction?
|
Same origin pages can already record and report this: instrument beforeunload and use sendBeacon to report the necessary timestamps. |
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 |
Navigation Timing doesn't contain any timings for the beforeUnload event.
As beforeUnload is triggered at the 'start of the navigation' from one page to the next, it's execution time affects users' experience
Some sites hook the event to determine whether it's safe to navigate e.g. will unsaved changes be lost, others use it to gather, compress and beacon back UX type data e.g. mPulse Resource Timing data, Tealeaf with DOM nodes.
I've observed beforeUnload event handlers take over 2s on mobile, so our current lack of timings leaves a blind spot and page timings that may not reflect actual users' experience.
I'm less sure about how we should record the timings for them though - moving the time origin seems a non-starter, as does having -ve values relative to time origin.
The text was updated successfully, but these errors were encountered: