So why don't google just disable the possibility of hijacking the back button in Chrome, to give an example?

dominicrose 9 hours ago | parent | next [-]

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.

	▲	nottorp 8 hours ago \| parent [-]
		> In a single-page application it may not trigger a navigation event. So isn't that also back hijacking?

▲

red_admiral 8 hours ago | parent | prev | next [-]

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.

	▲	nottorp 8 hours ago \| parent [-]
		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.

▲

9 hours ago | parent | prev | next [-]

[deleted]

▲

worksonmine 8 hours ago | parent | prev [-]

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.