Is there a cross-browser onload event when clicking the back button?

Is there a cross-browser onload event when clicking the back button?

For all major browsers (except IE), the JavaScript onload event doesn’t fire when the page loads as a result of a back button operation — it only fires when the page is first loaded.
Can someone point me at some sample cross-browser code (Firefox, Opera, Safari, IE, …) that solves this problem? I’m familiar with Firefox’s pageshow event but unfortunately neither Opera nor Safari implement this.

Solutions/Answers:

Solution 1:

Guys, I found that JQuery has only one effect: the page is reloaded when the back button is pressed. This has nothing to do with “ready“.

How does this work? Well, JQuery adds an onunload event listener.

// http://code.jquery.com/jquery-latest.js
jQuery(window).bind("unload", function() { // ...

By default, it does nothing. But somehow this seems to trigger a reload in Safari, Opera and Mozilla — no matter what the event handler contains.

[edit(Nickolay): here’s why it works that way: webkit.org, developer.mozilla.org. Please read those articles (or my summary in a separate answer below) and consider whether you really need to do this and make your page load slower for your users.]

Can’t believe it? Try this:

<body onunload=""><!-- This does the trick -->
<script type="text/javascript">
    alert('first load / reload');
    window.onload = function(){alert('onload')};
</script>
<a href="http://stackoverflow.com">click me, then press the back button</a>
</body>

You will see similar results when using JQuery.

Related:  How to know if .keyup() is a character key (jQuery)

You may want to compare to this one without onunload

<body><!-- Will not reload on back button -->
<script type="text/javascript">
    alert('first load / reload');
    window.onload = function(){alert('onload')};
</script>
<a href="http://stackoverflow.com">click me, then press the back button</a>
</body>

Solution 2:

Some modern browsers (Firefox, Safari, and Opera, but not Chrome) support the special “back/forward” cache (I’ll call it bfcache, which is a term invented by Mozilla), involved when the user navigates Back. Unlike the regular (HTTP) cache, it captures the complete state of the page (including the state of JS, DOM). This allows it to re-load the page quicker and exactly as the user left it.

The load event is not supposed to fire when the page is loaded from this bfcache. For example, if you created your UI in the “load” handler, and the “load” event was fired once on the initial load, and the second time when the page was re-loaded from the bfcache, the page would end up with duplicate UI elements.

This is also why adding the “unload” handler stops the page from being stored in the bfcache (thus making it slower to navigate back to) — the unload handler could perform clean-up tasks, which could leave the page in unworkable state.

For pages that need to know when they’re being navigated away/back to, Firefox 1.5+ and the version of Safari with the fix for bug 28758 support special events called “pageshow” and “pagehide”.

Related:  Duck Typing in Javascript

References:

Solution 3:

I ran into a problem that my js was not executing when the user had clicked back or forward. I first set out to stop the browser from caching, but this didn’t seem to be the problem. My javascript was set to execute after all of the libraries etc. were loaded. I checked these with the readyStateChange event.

After some testing I found out that the readyState of an element in a page where back has been clicked is not ‘loaded’ but ‘complete’. Adding || element.readyState == 'complete' to my conditional statement solved my problems.

Just thought I’d share my findings, hopefully they will help someone else.

Edit for completeness

My code looked as follows:

script.onreadystatechange(function(){ 
   if(script.readyState == 'loaded' || script.readyState == 'complete') {
      // call code to execute here.
   } 
});

In the code sample above the script variable was a newly created script element which had been added to the DOM.

Solution 4:

OK, here is a final solution based on ckramer’s initial solution and palehorse’s example that works in all of the browsers, including Opera. If you set history.navigationMode to ‘compatible’ then jQuery’s ready function will fire on Back button operations in Opera as well as the other major browsers.

Related:  How to merge two arrays in JavaScript and de-duplicate items

This page has more information.

Example:

history.navigationMode = 'compatible';
$(document).ready(function(){
  alert('test');
});

I tested this in Opera 9.5, IE7, FF3 and Safari and it works in all of them.

Solution 5:

I couldn’t get the above examples to work. I simply wanted to trigger a refresh of certain modified div areas when coming back to the page via the back button. The trick I used was to set a hidden input field (called a “dirty bit”) to 1 as soon as the div areas changed from the original. The hidden input field actually retains its value when I click back, so onload I can check for this bit. If it’s set, I refresh the page (or just refresh the divs). On the original load, however, the bit is not set, so I don’t waste time loading the page twice.

<input type='hidden' id='dirty'>

<script>
$(document).ready(function() {
  if ($('#dirty').val()) {
    // ... reload the page or specific divs only
  }
  // when something modifies a div that needs to be refreshed, set dirty=1
  $('#dirty').val('1');
});
</script>

And it would trigger properly whenever I clicked the back button.

Solution 6:

If I remember rightly, then adding an unload() event means that page cannot be cached (in forward/backward cache) – because it’s state changes/may change when user navigates away. So – it is not safe to restore the last-second state of the page when returning to it by navigating through history object.