ASP.NET Tricks: Dealing with the Back Button


Questions about the back button come up all of the time. A user gets a result set and then clicks back and wonders why their activities are not reflected when they hit back. Or they fill in a form and then hit back and submit again and wonder why there are two records (after all, the app is supposed to find their record after submission).

The issue with the back button is client side cache. One a page is hit, the rendered HTML is stored on the client side. If the user hits back, and has the default settings for their browser, it pulls from cache when they hit back and does not re-request the page. This causes a lot of problems with some applications.

First, let’s look at the browser. When you first open Internet Explorer (one example) and look at the caching options, they look like this:

TempFiles

What this states is the browser will decide automatically whether to pull from cache or go out and get the page. What IE will do is only request the page when it cannot pull from cache, or you have not browsed the page in quite some time, etc.

Disabling the Cache

I guess you could tell all of your users to change their browser settings and conquer this once and for all. 🙂

Programmatically, the cache is disabled by the following line:

Response.Cache.SetCacheability(HttpCacheability.NoCache);

Once you have this line in your Page_Load, the page will reload each time back is hit. This is fine in many instances, as it will try to reset everything up to the state when you first requested. But on a multi-part form, you can end up with trouble still, depending on ViewState settings, etc. What this does is send a “do not cache” header to the client.

Examining the Request in Fiddler, we see the following:

Fiddler1

Compare this to when the line is commented out:

Fiddler2

Disabling the Back Button

This is often the most sane choice with a very complex flow. It is rather easy to facilitate with JavaScript.

<script type="text/javascript">
    history.go(+1);
</script>

This is not actually disabling the button, so don’t use this in conjunction with the Response expiring method, or you can end up with this:

WebExpired

Of course sometimes this is not so bad, right? 🙂

Hiding the Back Button

This one is not so useful with Internet users, but is very useful with internal users. What you do, when the app is hit, is open another page in another window that does not have a back button.

<script type="text/javascript">

    function PopWindow()
    {
        window.open("default2.aspx",’Popup’,’toolbar=0,location=0,menubar=0′);
    }

</script>

and

<body onLoad ="PopWindow()">

This is the most effective, as the user does not have button, but the user can still hit the backspace key, so you need to add one more thing.

<script type="text/javascript">
    function checkShortcut()
    {
        if (event.keyCode == 8) {
            return false;
        }
    }
</script>

and

<body onkeydown="return checkShortcut()">

Here is a script someone else posted here. It is designed to work in IE7, which many forms of backspace button killing do not.

<script type="text/javascript">
    function killBackSpace(e) {
        e = e ? e : window.event;
        var k = e.keyCode ? e.keyCode : e.which ? e.which : null;
        if (k == 8) {
            if (e.preventDefault)
                e.preventDefault();
            return false;
        };
        return true;
    };
    if (typeof document.addEventListener != ‘undefined’)
        document.addEventListener(‘keydown’, killBackSpace, false);
    else if (typeof document.attachEvent != ‘undefined’)
        document.attachEvent(‘onkeydown’, killBackSpace);
    else {
        if (document.onkeydown != null) {
            var oldOnkeydown = document.onkeydown;
            document.onkeydown = function(e) {
                oldOnkeydown(e);
                killBackSpace(e);
            };
        }
        else
            document.onkeydown = killBackSpace;
    }
</script>

But this one comes with a serious caveat. If there is a textbox on the page, the user may need backspace, so you end up having to add a handler only to controls that are not textboxes. To overcome this, you have to addEventListeners for the individual controls that need the backspace that point to a routine that will return true. Unfortunately, I don’t have time to play with this right now.

Final Notes

One of the issues with all of these methods is newer browsers come out that no longer respect the old rules. The fact a rather complex script that adds event handlers is needed for IE7 and above is a prime example. One of the best things you can do to avoid the back button blues is design applications that don’t degrade when the back button is hit. ASP.NET MVC gives some good practices in this area, as the routing is through the query string, which means the user will redraw the form when they hit back if you expire cache. You can also work with ASP.NET, but you have to be sure that you do not end up with extremely complex, multi-part forms that have no means of returning state. ViewState can be your ally in many instances, so don’t be afraid to use it if you end up with this complexity.

I hope this helps you out.

Peace and Grace,
Greg

Twitter: @gbworld

Advertisements

3 Responses to ASP.NET Tricks: Dealing with the Back Button

  1. Quite a nice post and a very good thing to discuss but an important thing to note »» You haven’t provided any solution to this problem. All you have discussed are ways to compromise with this issue.

    At the most, you can do the following to tide with the problem :
    • Use Captchas

    • Actually, the captcha does not solve the back button problem directly. I can see where it might possibly help with a double submit, but this depends on the captcha implementation, as some captchas simply use a standard textBox for entry of the value. In those cases, a person hitting back and submitting again can submit the form twice.

      I was dealing more with the general problem of disabling a back button and not necessarily stopping double submit, although that is one reason. I may have to examine the “avoid double submit” problem, as there are multiple solutions. Overall, I would use captcha more to validate a human rather than stop double submit or as a way to avoid back button.

      Peace and Grace,
      Greg

  2. Rajesh says:

    great article

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: