beforeunload for post-pushState/replaceState navigations

[phistuck]

Many routers have the ability to stop a navigation, either by using the beforeunload event, or by re-pushing a navigation to the history.
The former works only when navigating would reload/load the top level frame.
The latter breaks back/forward in some cases.

Perhaps there should be a cancellable beforepopstate event that would prevent navigation from happening. Another feature could be a promise attribute (or maybe event.waitUntil) on the event object that would commit the navigation when resolved (say, the user decided to indeed leave the page).

[phistuck]

Related to #2710

[domenic]

Can you give an example of "many routers" and "some cases"? Unlike history.index, this is not something I have seen a lot.

[phistuck]

react-redux-router
It breaks the forward navigation in case history.index < history.length - 1. Basically, in case the user clicked on back, filled a form and did not submit, clicked on back and the router stopped the navigation by pushing the form entry again. The forward navigation is lost.

[phistuck]

See remix-run/history#690 for why the current situation does not work.

[annevk]

Duplicate this into #5562?

[phistuck]

@annevk - that one seems to be about monitoring navigations, not about preventing them and re-applying them.
Not sure how it resolves this problem.

[domenic]

Chromium is interested in solving this use case, as part of a larger overhaul of the history API to make it more suitable for single-page applications. Take a look, and feel free to comment with support, in WICG/proposals#20. In particular, the navigation monitoring and interception section touches on this.

[phistuck]

@domenic - hmmm, from the complete explainer -

Non-goals:
...
Provide any handling for preventing navigations that might lose data:
this is already handled orthogonally by the platform's beforeunload event.
...
Navigation monitoring and interception
...
It is not cancelable for user-initiated navigations via browser UI,
such as the URL bar or bookmarks.

Not sure how this solves this specific ("beforeunload for post-pushState/replaceState navigations") issue.
I agree the name of the issue might be confusing, since it actually talks about popstate after pushState/replaceState (for example, clicking on the browser back button).

[domenic]

Ah, OK, then yeah, there's no interest in letting developers intercept browser back buttons or URL bar navigations; that'd be too open to abuse.

[phistuck]

@domenic - so it is fine (I know it is not) for cross origin/non-single-page navigations but not for single page? A bit of a stretch. It is like encouraging non-single-page for not losing data, which sounds backwards.
:)

But I understand where you are coming from. Not agreeing, but understanding.

[phistuck]

By the way, preventing a locking in a user in a domain is a user interface issue and not a functional issue - the browser can show single-page entries and the last non-single-page (or even the last cross-origin) entry, making it easy for the user to get out of the site.