It's not clear what constitutes a hijacking and how they are going to detect it. It may be OK to override the button as long as it's used in the intended way which is to go back. In a single-page application it may not trigger a navigation event.
In an "application" model rather than a "document" one, like MS Word online or draw.io or similar, there's no clear semantics for "back" but there is a risk of the user losing data if they can navigate away without saving.
This is a consequence of sites being allowed to hijack back in the first place. They can still fix it.
For your use case all you need is the page to get notified so it can save. Remember that on Android your onSaveInstanceState gets called and you have to save your state or lose it.
This would break so many websites. There are valid uses for the history API, I often do modals/popups as shareable URLs, and using the back button closes it.
It's not clear what constitutes a hijacking and how they are going to detect it. It may be OK to override the button as long as it's used in the intended way which is to go back. In a single-page application it may not trigger a navigation event.
> In a single-page application it may not trigger a navigation event.
So isn't that also back hijacking?
In an "application" model rather than a "document" one, like MS Word online or draw.io or similar, there's no clear semantics for "back" but there is a risk of the user losing data if they can navigate away without saving.
This is a consequence of sites being allowed to hijack back in the first place. They can still fix it.
For your use case all you need is the page to get notified so it can save. Remember that on Android your onSaveInstanceState gets called and you have to save your state or lose it.
This would break so many websites. There are valid uses for the history API, I often do modals/popups as shareable URLs, and using the back button closes it.