Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This has been a cause of frustration for me on many sites like IRCTC, Online Banking sites which wont allow Back, forward or refresh. If you do you would be logged out and you have to login again. What I don't understand is what concern had there been in their mind to have such terrible "feature".

share|improve this question
IRCTC? Do you actually mean "IRCTC Online Passenger Reservation System"? Or is this some acronym that I can't find the meaning of? – Marjan Venema Jun 25 '13 at 11:48
@MarjanVenema: Yeah that railway reservation system. – Shubham Jun 25 '13 at 12:41
up vote 15 down vote accepted

A common reason for this "feature" is that a site tries to keep some state of the current session on the server side.

That desire to track "conversation" state on the server side often comes from trying to write a Desktop-like "rich client" on the web (as opposed to embracing the web as the chaos it is). To be fair, this mostly happened in a time when the concept of a rich web application wasn't as well-understood as it is these days.

For example if a site provides a multi-page wizard and tracks where exactly you are and what answers you have given, then supporting back/forward in a sane manner becomes complicated (because some operations don't get communicated to the server at all).

This complication sometimes goes so far that sites outright ban forward/back. As you noted, that has obvious usability problems.

share|improve this answer
It boils down to whether you can guess the user's intention when pressing forward/back. If you can't do so in all cases, then I can understand why some sites would elect to ban the use of such buttons. Of course, this could simply be down to poor design in the first case. – Robbie Dee Jun 25 '13 at 13:27
@RobbieDee - Yes, it's poor design. You can understand how someone might get there, if they have never seen the web before, but at this point it's well known that every browser has forward/back buttons, and frequently a long history. Anyone designing a web site that is broken by a standard browser feature like forward/back has screwed up, and needs to start over, rather than trying to make it work anyway. – Michael Kohne Jun 25 '13 at 17:14
I must confess to being firmly on the fence here. The nub of the problem (as Joachim points out) is desktop-like applications. We're trying to seamlessly mesh 2 different paradigms with mixed results. What should happen with the back/forward/refresh buttons isn't always clear. Consider also that web applications aren't always hosted in a desktop browser e.g. a kiosk. Your back/forward/refresh buttons will be whatever the interface says they are. It sounds like the History API may bring further order to the chaos. I don't know HTML 5 myself so I'll bow to Joachim's superior knowledge here... – Robbie Dee Jun 25 '13 at 18:57

Modern web applications (notably those written in MVC or similar) have no need for such navigation methods as the process flow is driven by the on-screen assets.

Much of the interface of modern browsers is however still very much geared towards Web 1.0 style web sites where the content is static and there isn't so much need for maintaining state.

Even knowing all the above is true, I agree that it is something of a pain to have such features taken away when they're now so natural to us.

I'd take a punt that future frameworks will have some way of hooking on-screen assets into browser back/forward/refresh buttons in a similar way to winforms apps where buttons could be assigned to the Enter and Escape keys.

An alternative could be for browsers to (somehow) detect the underlying framework and hide buttons not supported by the web application interface.

share|improve this answer
Back/Forward is a fundamental navigation concept on the web. Any good web application framework should embrace it (instead of trying to prevent it). And they can (by using the History API, for example). – Joachim Sauer Jun 25 '13 at 10:42
That is true for regular browsing but web applications are different beasts. Of course, the user doesn't care about all this - they just want the browser buttons to behave as they'd expect. – Robbie Dee Jun 25 '13 at 10:49
Web applications are "different beasts" only because they where designed that way. You can design a web application to embrace and support that navigation paradigm in a useful way. For example GMail just "does the right thing" when you press back: it cancels the last navigation in a meaningful way. It's just that many web applications are not designed/implemented that way. – Joachim Sauer Jun 25 '13 at 11:06
It rather depends on context as to what you find "useful". I have about 10 different GMail accounts for my wife's businesses. From the inbox I'd often like to go back to the sign-on screen to use another account. I press back and what happens? Nothing. It just stays in the current inbox. It doesn't do what I expect. This isn't wrong - it just isn't relevant to my context. I imagine 99% of the time, users would be happy with this behaviour. – Robbie Dee Jun 25 '13 at 12:38
Similarly for banking. I press a button to transfer money, a drop down appears (some Ajax magic) and I select an account and then move on to the amount field. Half way thru pressing the amount I notice I've selected the wrong account. What would you expect the back button to do here? – Robbie Dee Jun 25 '13 at 12:39

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.