battling with the back button

Recently, and also a few months back, I had a long drawn battle with the browser back button. There just seems to be something intrinsically broken with the web model using AJAX and that pesky button. In fact, even without AJAX, the back button in combination with form data seems to cause more than enough problems on its own. Consider my latest fight below.

My task was to repopulating a form when the user clicks on the back button. For those not familiar with the problem at hand, when a user clicks on the back button the page displayed is rendered from cache, and no request is made to the server. The actual page displayed when the back button is clicked may be in various states depending on both the browser being used, and the way this page was constructed in the first place, i.e. if it was rendered in stages with AJAX/JavaScript requests or just once when the page was loaded.

A simple, or not so simple, way to repopulate the form is by performing an AJAX call when the DOM loads, and either rendering the part of the page again and sending HTML in the response, or sending the form values back using JSON, etc.

Here I’m going to consider the first of these suggestions, but the problem I faced applies equally to the second (I think!). Let’s suppose that we make a request to the URL https://equivalence.co.uk/Step1/Index and that we are following some kind of wizard where we have “Previous” and “Next” buttons to navigate between the steps. Furthermore, let’s assume that the page rendered by default when accessing Step1/Index contains a form. Now suppose that we click the “Next” button and navigate to our new URL, say https://equivalence.co.uk/Step2/Index, and on this page we decide to hit the back button. As I described previously, on reloading Step1 we make an AJAX call back to the server, and importantly, we send the request to the same URL as the page we are currently on, i.e. Step1/Index.

When receiving this request on the server we check whether it’s an AJAX request or a simple GET then render accordingly. It’s probably reasonable to ask why the hell I was doing this, well if the server received an AJAX request there was no need to render the whole document again as I am only interested in the form element, but on the GET request I wanted to render the whole page.

However, this is where I ran into a little problem. Now suppose that we click the “Next” button again to move to Step2/Index and once again hit the back button. What is displayed?

Well as a surprise to me it was only the form, i.e. the response returned by the AJAX call, not the full page, no HTML head, nothing, just the form. Now that I have seen this behaviour, I totally understand why this is happening; the browser checks for the most up-to-date data sent for this URL, which in my case corresponds the AJAX request when the back button was hit previously. For some reason I just didn’t expect this – incidentally this was the behaviour on Firefox, I’m not sure what happens in the other browsers. As a result, when I was making the AJAX call I had to change it to make the call to “Step1/Index2” instead, now everything worked fine – I think maybe supplying a random get parameter to the original URL may also have worked.

So there we go, that’s it! Exciting post? Maybe not! Hopefully this helps someone though. It’s always something to bear in mind.

PS I’ve ended up with the weirdest problem ever whilst typing this entry in Google Chrome, it’s somehow messed up the keyboard mapping. As an example the top row on a QWERTY keyboard types as “azertyuiop^$” and you have to press shift to get the numbers. Strange.