A while back I had a couple posts on preventing double form submissions and showing an in-progress meter for long running pages. These work great, as long as you are using a type of validation that redisplays the form when there are errors.

This doesn’t work so well when you are not redisplaying the form. For example, I’ve seen some validation where the user is shown an error message and just told to use their ‘Back’ button to fix the errors. Sometimes a JavaScript history.go(-1) link is displayed as well. I had to work on a site today that used this type of validation.

I added a nice spinning wheel in-progress indicator, and some code to prevent the form being submitted more than once. But when FireFox users (2.x and 3.x) had an error on their form and used their ‘Back’ button, the form was redisplayed as they left it – without the DOM or JavaScript variables being reset. What I mean by that is the “in-progress” spinning wheel was still spinning (because a div element was still set to visible), and the submit button still said “Please Wait” instead of submit. And of course they couldn’t submit it after fixing their errors (because of the anti-double submit JavaScript code).

This didn’t happen in IE – the page was reset so that the in-progress meter was set to hidden, and the submit button value was back to its original state: “Submit” instead of “Please Wait”. I did a lot of googling to see if there was a way around this problem. I found many people asking this same question, but no good answers. Here is a large thread on Experts Exchange (scroll to the bottom to see all the answers) about this issue. You can see many people offer solutions which they are sure should fix the problem – but they don’t. Many people suggested using “onload” to set the submit button back to its original value. The problem is none of the JavaScript code is being run – onload won’t be run, nor will any other JS code you have in the page. Its served exactly as you left it, from your cache. On the subject of cache – setting this page to no-cache won’t solve the problem either, because then all the users form data will be gone.

But I finally did come across a solution. The existence of an onUnload function will make FireFox behave properly when going ‘Back’ to the previous page. I’m not exactly sure why this works, I’m guessing it has something to do with making FireFox register the page as unloaded, so that when you come back, it loads again, running any initial Javascripts that are defined.

You don’t have to actually do anything in your unload function, it just has to exist. You don’t have to have access to the

tag either, thank goodness, as this is sometimes hard to do within a framework.

Here’s how to define an empty onUnload function:

<script language="JavaScript">
window.onunload = function(){};
</script>

Thanks to the FireFox Answer site where I finally found this solution.

5 Comments

  1. Stephen says:

    Hi – this behaviour is due to Firefox 1.5+’s bfcache, as you found out.
    New events were introduced to be able to deal with the kinds of problems you found.
    Check out this page http://developer.mozilla.org/en/docs/Using_Firefox_1.5_caching
    Essentially you need to do window.addEventListener(“pageshow”, someFunction)

  2. Martin says:

    These events may be defined in the body tag too, like here :

    function noBack(){window.history.forward();}

    … blabla…

    This works flawlessly in FireFox as MSIE.

  3. BA says:

    Cheers dude, i was pulling out what was left of my hair with this problem!!

  4. Mike Harrison says:

    Thank you so much! This solved a major problem I was having with a jQuery drop down menu.

  5. Luiz DonĂ¡ says:

    Works for me!