[whatwg/dom] Proposal: onbeforereload to deprecate onbeforeunload (#655)

# Background

The `onbeforeunload` event has been historically both abused, and changed to prevent such abuse from sites that wouldn't let users go.

The way this event is currently useless for real-world applications can be summarized in here:

  * there's no `event.preventDefault()` ability, inconsistent with every other event
  * it might need a return value as string, which is also ignored (as never displayed) in modern browsers
  * it provides zero control for developers

Historically, the `onbeforeunload` event has been used either to trap users in a session, or to warn them something might break, or never been saved./restored, if the user actually leaves the page.

Yet there's no way to understand if the user opted in to stay, or opted out to close the page, or reload it.

## Reload Background

Reloading a Web page comes from the beginning of time, where dynamic, asynchronous, content wasn't there yet. It is, these days, still the only way users try to make broken websites work again.

And while it became a role of the user to be responsible of breaking SPA on demand, there's no control whatsoever for developers to understand when the user chose to reload, instead of close the tab, and that's a huge limitation compared with native applications, because there is no reload mechanism there (apps just work™) so the user knows how to close them and reopen them if something is truly off.

Being off, also usually indicate the quality of the app, so that apps that don't need to be force-closed and reopen all the time are usually preferred, but we instrumented Web users since ever to refresh to fix the issue or see new content (TL;DR we blame users for the broken UX and code we deliver as developers).

# onbeforereload use cases

To start with, knowing it's a reload request, instead of a close tab/window one, is a whole new world of metrics and guidance opportunity.

Every browser exposes a refresh button since 90's, and the `reload()` method also works since about ever.

If we had an `event` able to tell if the event was trusted (user using cmd+r or F5 or any way to refresh the page) as opposite of self invoking it `location.reload(true);` developers can decide what to do about it, with the ability to inform users that if they reload something might break.

```js
window.onbeforereload = event => {
  if (!event.isTrusted) return;
  if (confirm('Are you sure?')) {
    location.reload(true);
    return;
  }
  // prevent the user from accidentally reloading
  event.preventDefault();
  sendMetrics();
  refreshContent();
};
```

## Web Extensions too

If you consider the current tabs API for Web extensions, you'll realize there are methods such `tabs.captureVisibleTab` that are based to the current visible tab, and if you operate some operation to that image, and you show such result into a new tab, once the user refresh the page `tabs.captureVisibleTab` would point at the newly active one, not the initial anymore.

To handle this with current priorities is very messy, and error prone, while having a way to inform the user, on accidental reloads, that things might break, would save everyone a lot of time.

Knowing the user decided to reload anyway, is good enough, as indication, to eventually close the current tab and bring the user where all started, the active tab the user tried to elaborate.

## Not only extensions

I feel like a proper event for something that cannot be possibly handled on the Web but is one of its most historical curses, compared to native applications, would be more than desirable for everyone writing Web apps a bit more complicated than a stream of tweets that needs to be force-refreshed due some JS issue underneath.

After all, having the ability to interfere or not, should be a distributor (of news, app, tweets, whatever) choice, where the user, if done properly, can still be in control of the choice, in case it wasn't accidental (and the Web app/SPA provider, can also know about it).

Thanks in advance for considering this improvement for the lifecycle of a generic page.







-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/655