Often when I’m googling something I’ll go to a few pages, so I’ll click a link, and then use the back button to return to the search results and find another link. But sometimes the back button just reloads the page, and even tapping it multiple times doesn’t work. How and why do some websites do this? Surely it should be my browser that’s controlling if it goes back or not, rather than the website it’s on?
In: 197
I think some people have done a good enough job at explaining how the concept is abused at a high level, but to go a step deeper:
You wouldn’t want to go back to a “logging you in” page, just like you wouldn’t want to go back to a “charging your credit card” page. Because there is no standard for what those pages are named, what URL they’re at, et cetera, the browser has no idea how to avoid them.
And that’s a simple case. Let’s say that a purchase requires multiple pages for filling out options and payment and shipping: if you succeed in paying and you click “back” not only do you not want the “charging your card” page, but you also don’t want the 5 “fill out your details” pages, either. You probably want your cart, or the last page you were on, before you hit “buy”. *But* if you are in the middle of the purchase and you are on page 3 of the forms and you hit back, you would expect to return to page 2.
There are even some sites where the pages don’t change; different widgets open and close. Some of those widgets might take up the whole page, or look like options menus. Slack and Skype, for example, are technically web pages. Even the desktop versions are apps running inside of a single webpage. Phones have taught us that “back” should return us to the previous state of the app, even if it’s not technically a different URL.
Developers need to handle this, because the Chrome team or the Firefox team can’t write all of these different understandings of “back” into every path of every website.
This is the History API in browsers, and it’s a little (lot) wonky, but it’s necessary.
The History API works like a stack. For non-programmers, a stack is basically what it sounds like: a stack of stuff; you add a thing to the top of the stack when you want to remember it for later, and you pull a thing off the top of the stack when you want to go back to it.
In most mobile apps, this stack is essentially the view that you are looking at… like, what window or panel or pane is currently open. When you pull something off the stack, you are essentially throwing out the view that you are on, and going back to the one before that. As a mobile app (I dunno, think Spotify or an email client), these aren’t web pages, but different views, that you can still go back through.
In the History API in the browser, it’s basically just the URL that you were on, and a few small details that you can keep track of.
But web developers need to be able to play Jenga with that stack, to prevent your card from being charged twice on old-fashioned sites, or to prevent weird things from happening with your login, et cetera. Some jerks hijack this to give you the crappy experience that you have.
There is a better API coming for letting devs control the flow in the app, without preventing the browser from doing its job… But that API is a long way off; first it needs to be made, second it needs to be adopted by everyone, third, the History API needs to be canned, or updated to not hold you hostage, once the better alternative API is widely used… but we are talking years, here. The History API is 10+ years old now, and hasn’t had many changes since… adding the new Navigation API to all browsers, and then getting devs onboard will probably be another 5.
Latest Answers