> Which actions defines a history-worthy state change? Should clicking around a menu generate 10 history events? What about toggling a checkbox? What about an a

> Which actions defines a history-worthy state change? Should clicking around a menu generate 10 history events? What about toggling a checkbox? What about an action that changes most of the information on a page? Should that generate a history event? What if that action is bringing an in-app tab to the forefront? What if there is an obvious history event that should be generated, but there is no good reason for why a user would want to go back to that state? These are great questions, but they kind of apply to a different level of the design than my litmus test. Start with not making it more complicated than it is: browser history is browser state that we should be able to go back to. When this is not the case, it does not go into browser history (strictly speaking about using the JavaScript history API here). Otherwise, we need to ask and answer questions like the one you posed. And at that point, "does this break the back button?" is a good first question to ask oneself to ensure we think things through and figure out what it is that we are really trying to achieve. > What if state should be destroyed when you press the back button? That says something about which state of the current page is going to be stored in the history, not which state of the previous previous pages has been stored. > What if I open an image in a photo app, click a button to delete it, and go to a 'deletion successful' page. This is a solved problem! The "deletion successful" message should not be its own page to begin with, that's what makes it look more complicated! A modal pop-up is the right answer here. (tangent: I'm sure we both agree that many problems are caused by trying to fix issues created by using the wrong initial solution) If all of this happens within a photo app, the app is the page, which we never left; we clicked a button, not a link. App state history is not the same as browsing history, so if, and only if, we want to preserve snapshots of the photo app state, we use replaceState and/or pushState. In the case where different pages are warranted, for example within a photo gallery on Facebook or Imgur, the pop-up still happens on the page linking to the uploaded-but-now-deleted photo, followed by a redirect to, say, the main gallery. The link to the uploaded photo should then become a 404 page, because it is now an invalid link. In both cases, the "deletion successful" modal obviously does not need to be preserved in the browser history. > It doesn't even matter how you answer all of the above questions - other people will have different answers for them, and have different expectations for how the back button should work, on the same app. And some of those answers will be right, most will be wrong, and some will depend on the desired context. But presenting hypothetical exceptional cases does not prove there is no such thing as really obviously bad design. There are exceptions, but they are just that: exceptions. They don't invalidate the question as a good first guiding principle to start from. If anything, doing provokes these questions: you came up with them in response to the implied question "what does it mean to break the back button?" That is a lot better than just slapping something together without thinking about it.