Breaking the back button is an unfortunate consequence of SPA (single page application) frameworks like React. You'd be amazed at just how easy it is to do. Put a junior on a feature and unless there's process in place to look for back button breakage, it can easily find its way into production. Even if you have QA resources, browser history management is not going to be within their wheelhouse so all they can do is note that it's happening and maybe they can give you a rough idea of which feature caused it.
Essentially, SPA architecture replace page loads with changing the DOM directly. Changes to the DOM don't change browser history unless you tell it to. Breakage can happen in two ways. First you can change things without updating browser history, or you can make changes that update history without actually changing the page. Both break the natural flow of the back and forward buttons.
The easy answer is to tell devs to just make new page loads when necessary, but apps can complicate to the point where page loads mean a great deal of reloading stuff. Then the next answer given to devs is to not load lots of stuff, but loading lots of stuff is often dictated by business needs and is over the devs' heads. Good luck moralizing on business people.
Once I saw how often such breakage slipped into the web app that I work on, I got a lot more patient with other websites. It's actually a really hard problem that I'd put right up there with cache invalidation and naming things. There's no established doctrine for browser history management.
> I got a lot more patient with other websites. It's actually a really hard problem
Definitely true in my experience. If I go to a page which contains an image from a web cam and a slider or links or butttons with times, I want to be able to click around on times and see the image from that time -- but I don't want to have to backtrack through all times I have viewed to go back to the previous page.
I guess what I'm saying is that it's hard to nail down what a "location" is in terms of UX. If the context is roughly the same, with only minor elements of the page change, I expect to be able to bookmark that view, but my back button should take me farther back.
Essentially, SPA architecture replace page loads with changing the DOM directly. Changes to the DOM don't change browser history unless you tell it to. Breakage can happen in two ways. First you can change things without updating browser history, or you can make changes that update history without actually changing the page. Both break the natural flow of the back and forward buttons.
The easy answer is to tell devs to just make new page loads when necessary, but apps can complicate to the point where page loads mean a great deal of reloading stuff. Then the next answer given to devs is to not load lots of stuff, but loading lots of stuff is often dictated by business needs and is over the devs' heads. Good luck moralizing on business people.
Once I saw how often such breakage slipped into the web app that I work on, I got a lot more patient with other websites. It's actually a really hard problem that I'd put right up there with cache invalidation and naming things. There's no established doctrine for browser history management.