Users do expect that any back button takes them “back”, indeed. What exactly they consider “back” may differ (usually their previous view, i. e. the appʼs previous state, which may involve “closing” active dialogs) and it may differ from the authorʼs idea of “back”. Users are always confused if there are two back buttons (or any other duplicate control) and they are even more confused if those work differently. So, Iʼm in total agreement with:
A user doesn’t expect that clicking the back arrow inside the HTML or the back arrow provided by the mobile OS gives him different results.
and the way to fix this is either not providing any “back arrow inside the HTML” or making its only ever action
history.back(). Thatʼs simply the other way around from:
It would greatly improve the UX if we could set the OS back button (…) to the same value as the inner website navigation.
As has been said, if you cannot be RESTful for some reason, there is already an API (
replaceState()) to add PWA views or states to the browser history – actually there are two, the other being
If you are actually talking about previous / next relationships, like I mentioned, then you are really asking for new browser UI controls (which I would support). Opera and early Firefox used to support
rel link relations that way.