Why do browsers not keep status 302 pages in back-button history? | Hacker News Reader

Why do browsers not keep status 302 pages in back-button history?

stackoverflow.com

39 pointsOJFord13 comments

I wish there was a way to keep all redirects in the back button history. For me, one of the most infuriating things on my work computer was starting up the browser after a period of inactivity (eg. the weekend) and seeing every Jira/Github/whatever tab sitting at the corporate SSO page. The original page wouldn't be in the back history so I effectively "lost" those tabs. Firefox fortunately keeps most tabs suspended on startup nowadays so it's less of an issue.

This is a jira/gitlab problem. They should recognize the page requires authentication, get that auth, then take you back to the page your browser requested.

Oh, they do. It's just that restoring 20 tabs on browser start results in 20 SSO pages and I have to log in each one of them separately to return to the original pages. I can't do something like logging into one and hitting the back button on the rest.

I think you can log into one and then click the refresh button on the rest?

It'd be awesome if that worked, but unfortunately the SAML implementation my company uses doesn't work that way. A refresh just presents the username/password fields again.

When I work in Jira or ServiceNow I never have that issue. I SSO in one tab and then refresh the other ones. Our sso must be different because I don’t see the splash page until the app realizes I need to sign in again.

Because when the original URL always gives a 302, that creates a terrible user experience: hitting back would give you the current page again. Browsers can't know whether a 302 is transient or persistent.

Good point, though that would only be a problem if you let it. If you click-hold the back button in the browser 'chrome' you typically get a list from history. (I'm not actually sure if this behaviour is also present in actual history.) You could skip past ongoing temporary redirects using that feature; it is already necessary when that behaviour is implemented in JavaScript instead of standard HTTP status codes.

Also this is about temporary (302 Found) redirects, not permanent.

Very few people want to have a probabilistic back button where sometimes it works and sometimes you have to hold it down to go “deep back”. We complain about history pollution all the time on HN which is what your proposal would amount to, and it would be very confusing for most people.

On mobile, it’s not obvious where you’d stuff power user UI for redirect chain analysis. On desktop, you can keep devtools open or even create a browser extension with the exact UX that you want for this.

If the page is temporarily redirecting, that's already being experienced?

Also, the status quo is that history is polluted by bad behaviour and (or including) non-HTTP redirects. Excluding HTTP redirects from history does nothing to fix that, just makes it worse really: I don't think misbehaving sites doing things that shouldn't be in history are bothering with 302s.

The extended back history is also available in Firefox by right clicking the back button. I’ve also found this feature in iOS Safari and Firefox. For the latter you press and hold back.

302 is temporary. 301 is permanent.

Temporary doesn't have to be transient.

Reply on news.ycombinator.com