Practical ASP.NET
Suppressing the Back Button: Just Say No
I teach a couple of courses on ASP.NET for Learning Tree International (one of which I wrote). Often a participant will come up to me, usually on the third day of the course, wanting to know how to disable the Back button on the browser. I first explain that the Back button is processed entirely inside the browser and handled by the browser working its way back through a cache of pages that it's already retrieved. Since there's no trip to the server, our server-side code doesn't run. You can't disable the Back button with server-side code.
If you've read my previous columns, you'll know that I can only suppose that you could handle the problem in JavaScript. Read this discussion of the problem, which I like. But quite frankly, browsers are designed to stop you from holding the user on the page.
Staying 'Webby'
More importantly, disabling the Back button isn't "webby" behavior. To me, the request indicates that the developer is trying to move a desktop paradigm to a browser-based app. I encourage the participant to try to write their application so that it doesn't matter if the user hits the Back button.
In a browser-based application, this means that you're striving to make each page a standalone item that is completely independent of other pages. If you do that then it won't matter what page the user was on before the current page. If the user goes back to the previous page, it won't matter.
Of course, not all transactions can be fit onto one page. The Wizard control can be helpful here because it lets you handle a multiple-step process on one page. With the Wizard control, the user can move back and forward through the Wizard's steps without leaving the page.
Handling the user clicking the back button inside the Wizard control does require some planning. The key is to take no action until the user clicks on the Finish button. If the user wants to move back and forth between the Wizard's steps prior to clicking the Finish button, then there's no problem because you haven't changed anything. When the user clicks on the Finish button, you'll have access to all the data on the page in all of the Wizard's steps and can perform any updates you want -- and then send the user to a Finish step.
An ASP.NET Solution
If I can't talk you out of trying to disable the Back button, I tell my class participant's that the best way to get something like what they want is to force the previous page to expire. This solution isn't about disabling the Back button but selecting pages that you don't want the user to return to. When you force a page to expire then, when the user hits the Back button and returns to the page, the browser is forced to go back to the server to retrieve the page -- this gives your server-side code a chance to run.
Furthermore, this solution assumes that you have control over the user's previous page. The user may come to your page from another site in which case this solution won't work. It also assumes that you know what the "previous" page is, so that you can set it up to expire. If the page that the user is going to can be reached from any page on your site... well, you probably don't want to apply this solution to that many pages.
The user will also probably get a message that "The page has expired," which may not fit into your vision of your site's user interface. Back on the server you can use Response.Redirect or Server.Transfer to send the user to the page you want.
This directive, added to a page in Source view, will do the job on most browsers:
‹%@ OutputCache location="none" Duration="1" VaryByParam="none" %›
You also do it from code by calling the SetCacheability method:
Reponse.Cache.SetCacheability(HttpCacheability.NoCache)
You know what? Another choice is to put a message on the page telling the user not to use the Back button. And, yes, I have no faith in this solution, either, but I've seen lots of sites use it. But, since you shouldn't be doing trying to do this at all, I figure it's as good a solution as anything else in this column.
About the Author
Peter Vogel is a system architect and principal in PH&V Information Services. PH&V provides full-stack consulting from UX design through object modeling to database design. Peter tweets about his VSM columns with the hashtag #vogelarticles. His blog posts on user experience design can be found at http://blog.learningtree.com/tag/ui/.