After travelling back in Firefox history, JavaScript won't run

Asked 14/4, 2010 at 14:42 Answered 7/4, 2021 at 19:41

Solved javascript firefox

When I use the back button on Firefox to reach a previously visited page, scripts on that page won't run again.

Is there any fix/workaround to have the scripts execute again when viewing the page the second time?

Please note that I have tested the same pages on Google Chrome and Internet Explorer and they work as intended.

Here are the files and the steps I used to test the problem:

(navigate to 0.html, click to get to 1.html, back button)

0.html

<html><body>
<script>
  window.onload = function() { alert('window.onload alert'); };
  alert('inline alert');
</script>
<a href="1.html">Click Me!</a>
</body></html>

1.html

<html><body>
<p>Go BACK!</p>
</body></html>

Nimiety answered 14/4, 2010 at 14:42 Comment(0)

101

Set an empty function to be called on window.onunload:

window.onunload = function(){};

e.g.

<html><body>
<script type="text/javascript">
  window.onload = function() { alert('window.onload alert'); };
  window.onunload = function(){};
  alert('inline alert');
</script>
<a href="1.html">Click Me!</a>
</body></html>

Source: http://www.firefoxanswer.com/firefox/672-firefoxanswer.html (Archived Version)

Grozny answered 14/4, 2010 at 14:49 Comment(9)

Thank you, it works. Any hint on what does the default onunload handler do? (e.g. am I overriding a default behaviour of some sort here?) – Nimiety 14/4, 2010 at 14:55

Ok thanks, I'll investigate. Thank you again, this problem has been haunting me for a while :) – Nimiety 14/4, 2010 at 15:1

anybody know why FireFox needs this while other browsers do not? – Dingy 14/4, 2010 at 15:12

You're not overriding anything, this just prevents Firefox from caching the page in the Back-Forward Cache (bfcache). developer.mozilla.org/en/DOM/window.onunload developer.mozilla.org/En/Using_Firefox_1.5_caching – Kwarteng 14/4, 2010 at 15:34

www.firefoxanswer.com link is dead, but @Chris's link works - developer.mozilla.org/en/DOM/window.onunload lists the reason in the Notes section – Randall 19/12, 2012 at 12:58

While it should break bfcache unfortunately it seems it still remembers the previous page - specifically, iframe urls that were loaded are loaded again when you go back, and if generated content needed to be placed in the frame, there doesn't seem to be crossbrowser way to refresh that anew. – Hansel 20/1, 2015 at 16:6

if you use jQuery, I suggest to use $(window).on('unload', function() {}); – Senary 29/6, 2016 at 12:58

In MDN, unload is documented to prevent this caching only with Firefox 1.5 (and not in all pages about it), while beforeunload is documented as preventing this caching without mentionning a specific browser version. So currently it seems better to use beforeunload if you want to use this hack instead of this solution. – Brinton 26/11, 2019 at 18:7

Keep in mind onunload generally isn't good for mobile as many (most?) mobile browsers don't actually fire that anymore. Consider instead the Page Visibility API. Here's a short explanation I find useful: igvita.com/2015/11/20/… (if you're not concerned with mobile, you're probably not doing it right...). Also, +1 for proposing a non-jQuery solution. – Feltonfelts 7/6, 2021 at 16:12

When I use the back button on Firefox to reach a previously visited page, scripts on that page won't run again.

That's correct and that's a good thing.

When you hit a link in Firefox (and Safari, and Opera), it does not immediately destroy your page to go onto the next one. It keeps the page intact, merely hiding it from view. Should you hit the back button, it will then bring the old page back into view, without having to load the document again; this is much faster, resulting in smoother back/forward page transitions for the user.

This feature is called the bfcache.

Any content you added to the page during the user's previous load and use of it will still be there. Any event handlers you attached to page elements will still be attached. Any timeouts/intervals you set will still be active. So there's rarely any reason you need to know that you have been hidden and re-shown. It would be wrong to call onload or inline script code again, because any binding and content generation you did in that function would be executing a second time over the same content, with potentially disastrous results. (eg. document.write in inline script would totally destroy the page.)

The reason writing to window.onunload has an effect is that the browsers that implement bfcache have decided that — for compatibility with pages that really do need to know when they're being discarded — any page that declares an interest in knowing when onunload occurs will cause the bfcache to be disabled. That page will be loaded fresh when you go back to it, instead of fetched from the bfcache.

So if you set window.onunload= function() {};, what you're actually doing is deliberately breaking the bfcache. This will result in your pages being slow to navigate, and should not be used except as a last resort.

If you do need to know when the user leaves or comes back to your page, without messing up the bfcache, you can trap the onpageshow and onpagehide events instead:

window.onload=window.onpageshow= function() {
    alert('Hello!');
};

Iconoduly answered 14/4, 2010 at 16:27 Comment(15)

My problem is that bfcache does not cache ALL the page so I have to re-run js to rebuild lost content. So thrashing the whole page could be ok. Anyway, I'm not using the window.onload event, I'm using jQuery document.ready event. Do you know a way to still be able to use document.ready and avoid this problem? – Nimiety 15/4, 2010 at 10:7

bfcache should in general return the entire page as it was when it was left. What is the content that's missing after returning from the previous page? (test case?) document.ready will work essentially in the same way as window.onload (for some browsers, they are the same event anyway). – Iconoduly 15/4, 2010 at 11:14

That is NOT a good thing because it doesn't run the javascript again, considering it cached...but DOESN'T actually cache the changes the javascript had made previously. If the javascript fades in an element on page load, it doesn't fade it it again when visiting in history...but DOES start it on 0 opacity again, undoing what the javascript had done! It has to be ALL OR NOTHING. You must cache the complete state of the page after the javascript has run if you want to present it cached without running the javascript again! – Predesignate 18/12, 2012 at 18:15

@Jimbo: Test case please. bfcache is intended to (and in every case I have ever seen, does) preserve the exact state of the DOM over hide/show. An element that had been faded in will remain opaque when the page is returned to, unless some other script runs to hide it again. – Iconoduly 19/12, 2012 at 10:1

@Iconoduly - Make an element with a CSS file setting the opacity to zero and then use some jQuery to make it fade in on the document ready. Upon going back in history it will reapply the stylesheet CSS (the zero) without keeping the opacity:1 that the JS added to the style attribute when fading it in. First time you visit the page the element will fade in from zero to 1. Go to another page and hit back and it will just sit there fully transparent. – Predesignate 28/12, 2012 at 19:33

@Jimbo: Works for me - fiddle.jshell.net/h9ap6/1/show/light . CSS doesn't work the way you imply. Stylesheets are constantly, dynamically applied to the rendered form of a document. They do not affect the actual DOM at all; the inline 'style' property of a specific element is never touched by an application of stylesheet rules and there is no 're-application' at page show time. – Iconoduly 28/12, 2012 at 22:16

@Iconoduly - That's not how I implied CSS works. I said since it did not keep the contents of the style attribute (as was originally changed by the JS) upon going back in history, but did keep the CSS sheet declaration (which that part of course it was supposed to) that the element ends up at opacity 0 instead of 1. – Predesignate 30/12, 2012 at 17:46

@Iconoduly - Your demo does work for me. But I have a theme in which this issue was found by multiple users, and I confirmed the its existence with my own tests. The state of the style attribute was not kept upon using the back button, confirmed by multiple non-affiliated people in different places on different machines. My explanation for it was as I outlined above, though your demo shows that my explanation of what was happening must be oversimplified. I'll look more into it and figure out why in the case of my theme the style attribute was not retained, then hopefully we'll have more info. – Predesignate 30/12, 2012 at 17:51

I had the same problem, the bfcache does not seem to work well when plug-ins are involved. After coming back to the page it complained about invalid JSAPI objects. Re-running the JS on the page is the only right thing to do in this case. – Perpetuity 23/7, 2013 at 15:3

@Fozi: Again: test case please. If you have genuinely found somewhere where the browser fails to recover the page JS/DOM state, then that is a bug and needs a repro case to be reported. Usually, the answer is simply that one of the scripts actively breaks something about the page, but it goes unnoticed as the page is not returned to without bfcache. – Iconoduly 23/7, 2013 at 16:39

@Iconoduly Sorry, no test case, but here is the scenario: Our plug-in allows access to credential hardware. There is a static <object> tag and in window.onload access to the device is acquired. This access is exclusive so when the user leaves the page the access is revoked. Moreover according to the rules of NPAPI the plug-in internal objects for this page instance can be released at this point. When the user presses the back button the device object is in an invalid state. Hoping that this works for any NPAPI plug-in is relying on a memory leak. – Perpetuity 23/7, 2013 at 16:49

Oh! I didn't realise you meant native browser plugins. These are naturally outside the scope of JS/DOM so can't be recovered. It's still possible to make them work without breaking the bfcache by re-initialising them on the pageshow, but yeah, it is the one thing that doesn't naturally work. – Iconoduly 24/7, 2013 at 9:16

Thanks a lot, i've been searching for a solution like onpageshow for quite some time now. Works like a charm! – Theodoretheodoric 25/1, 2017 at 12:17

For me, the LastPass browser extension disabled the bfcache. My body onload handler was called when going back on my dev machines, so some widget was properly recreated - but for some co-workers it just wouldn't work, and the widget didn't update. A window.onpageshow handler to update the reloaded DOM should do the trick. Thanks! – Determinism 27/4, 2021 at 8:34

@Attacktive Now that archive link is rot :) Replace with web.dev link. – Evening 10/8, 2022 at 21:24

You can check the persisted property of the pageshow event. It is set to false on initial page load. When page is loaded from cache it is set to true.

window.onpageshow = function(event) {
    if (event.persisted) {
        alert("From bfcache");
    }
};

For some reason jQuery does not have this property in the event. You can find it from original event though.

$(window).bind("pageshow", function(event) {
    if (event.originalEvent.persisted) {
        alert("From bfcache");
    }
});

Mosher answered 29/9, 2012 at 0:8 Comment(3)

Thanks for providing both javascript and jquery versions! You missed a close bracket at the end there (this isn't a moan!). I'll also note, for the sake of others, that IE and Chrome report .persisted is always false, regardless. – Kenner 5/11, 2012 at 18:7

As noted by Magnus, this didn't work for me in Chrome until I removed the if statement. – Ornamented 29/8, 2014 at 17:45

This worked for me in Chrome 58.0.3029.110 (64-bit) and FF 53.0.2 (64-bit) without any changes. – Interdenominational 27/5, 2017 at 6:0

In my case window.onunload with an empty function didn't help (I tried to set a value for dropdown when user uses backwards button). And window.onload didn't work for other reason - it was overridden by <body onload="...">.

So I tried this using jQuery and it worked like a charm:

$(window).on('pageshow', function() { alert("I'm happy"); });

Britton answered 7/4, 2021 at 19:41 Comment(1)

This tip helped me to prevent displaying a JQuery loading div (based on $(document).ready) while clicking the back button. I finally did it after hours of searching, thank you so much ! – Commendam 13/12, 2022 at 14:28

Wire in an "onunload" event that does nothing:

<html><body>
<script type="text/javascript">
  window.onload = function() { alert('window.onload alert'); };
  window.onunload = function(){}; 
  alert('inline alert');
</script>
<a href="1.html">Click Me!</a>
</body></html>

Kwarteng answered 14/4, 2010 at 14:48 Comment(5)

Not sure, I gave a up vote, looks like someone just downvoted every answer to this question... – Nimiety 14/4, 2010 at 15:2

you should add to your answer that adding the onunload event to your page will actually disable the page being cached in its entirety. This does not simply make the JS run again, it will also make the server load go up a notch. This is really not a suggestion to take lightly, this should be carefully considered. – Evangelicalism 26/2, 2015 at 10:53

@dreagan, this disables the bfcache but not necessarily the HTTP cache. The HTTP cache has a whole other set of rules. If you throw a server-side sleep in there you should notice it during the click back. Mozilla talks about this in their third question on the FAQ for BFCache. – Kwarteng 26/2, 2015 at 14:17

I was talking about the BFcache, should have specified that. That does not mean you should give out a suggestion like this without notifying the OP of the consequences. An alternative would be to use the onpopstate event to try and fire the javascript again. – Evangelicalism 27/2, 2015 at 7:40

I still don't know if I understand. Why would "the server load go up a notch" if the client's local bfcache gets bypassed? Yes, the DOM will need to be rebuilt, but the HTML should be part of the client's HTTP cache. Yes, additional resources will need to be reloaded, but those should be part of the client's HTTP cache, too. As for the onpopstate, when this question was asked almost five years ago that event was still relatively new and browser support was very inconsistent – Kwarteng 27/2, 2015 at 14:42

As far as i know Firefox does not fire onLoad event on back.

It should trigger onFocus instead based from this link here.

Recrement answered 14/4, 2010 at 14:52 Comment(1)

Tested it and windows.onfocus DOES indeed get called, even without setting the empty window.onunload handler. Setting onunload is a slightly nicer workaround but .onfocus should be fine too. Thanks :) – Nimiety 14/4, 2010 at 15:21

A simple way to cause a page to execute JavaScript when the user navigates back to it using browser history is the OnPopState event. We use this to pause and replay the video on our home page (https://fynydd.com).

window.onpopstate = function() {

    // Do stuff here...
};

Illbehaved answered 9/2, 2016 at 2:10 Comment(1)

OP is not asking about a single page app with a hash change, but literally navigating back to the first page with history.back. – Teaching 29/12, 2021 at 12:16

-1

for some cases like ajax operations url change listener can be used

$(window).on('hashchange', function() {
        ....
});

Schuss answered 26/11, 2015 at 10:35 Comment(0)

Hot tags

Godot Unity Godot Help Programming Godot 4.X GUI GDScript 3D 2D Physics CSharp Godot 3.X VR XR Projects C++

Recommended topics

Hot tags