Internet Explorer 11 Back Button Javascript Behavi

Question

In Chrome, FF, and IE8-10, when I press the back button, my javascript $(document).ready() function is called, but in IE11, none of the javascript is invoked. Does anyone know how to make IE11 respond like all the other browsers and bring consistency to my code?

<script type="text/javascript">

    alert("Are we called?"); // neither is this called in IE11
        $( document ).ready( function() {
            alert("document ready"); // does not get fired after hitting back on IE11
        });
</script>

The annoying issue about IE11 is that if you turn on developer tools and start trying to trace or debug the issue, it goes away and it behaves as IE10 and calls the .ready() after going back.

I do have cache disabled on this page via this header and again, it works on all other browsers that I am looking to support (IE8-10, FF, and Chrome).

Cache-Control: no-cache

Answer 1

I also have encountered this issue, which is clearly not a bug if you read IE Doc. As wrote Robert Daly, take a look to http://msdn.microsoft.com/library/ie/dn265017(v=vs.85).aspx You can find on this doc that beforeunload event prevents BF cache. So here is a short peace of code that defines this event writing on the console to prevent BF cache:

if (typeof window.onbeforeunload != 'undefined'){
   function doNothing(){
      console.log('Prevent BF Cache');
   }
   window.onbeforeunload = doNothing;
}

Answer 2

Alright, after pounding away at the problem for the past 2 hours, here's my findings.

The following events are never called between back and forward:

• load/onload
• unload/onUnload
• change/onchange
• or any of the other events that looked like it might be called on back/forward

IE11 caches everything on page including the javascript state so none of the usual events are fired. When going back and forth between a page via the back/forward buttons, javascript code just resumes state without being notified that it was interrupted. Sorta rude to developers imho or maybe there is an event that is triggered for this, but I certainly don't know about it.

Anyways, you can see this behavior on this page full of balls. Note in IE11, you navigate to google.com and then press back, all the balls are in the same exact location and everything continues to work. In every other browser, the page is reinitialized and the the balls drop fresh from the ceiling again. I can see scenarios where IE11 behavior would be useful and beneficial, but I just wish Microsoft would provide documentation for when you don't want it like that. Also, it would be nice if the defaults would be like every other browser and making this feature optional instead of breaking all compatibility with everything, including its own IE9 and IE10!

So with that, I realized that if I started a timer, it would just pick off from where I left off. I don't like this code as it is a busy-wait hack, but it does what I want. It would be great if someone could think of something better that wouldn't be so busy...

<!-- IE11 back/forward hack - http://stackoverflow.com/questions/21274085/internet-explorer-11-back-button-javascript-behavior -->
<script type="text/javascript">
    var dumbIEHistory=history.length;
    function busyWaitCheckForHistoryChange() {
        if (history.length != dumbIEHistory) {
            alert("History has changed, back/forward has been pressed, run my function!");
            myFunction();
            dumbIEHistory=history.length;
        }
    }

// using http://www.pinlady.net/PluginDetect/Browsers/ to do browser detection
    $( window ).load(function() {
        if (browser.isIE && browser.verIE >= 11) {
            // let's not bog down all the other browsers because of IE11 stupidity
            window.setInterval("busyWaitCheckForHistoryChange()", 1000);
        } else {
            // in other browsers, this will be called when back/forward is pressed
            myFunction();
        }
    });
</script>

Works for what I'm doing to catch when the back/forward button is pressed because the history length will be +1 after we hit back. If the user navigates back and forth too quickly, there might be a split second before the function is called, if that is a concern, you can reduce the interval. Hope this helps others.

Answer 3

you can use window.onhashchange to monitor behaviors of the back/forward buttons.

var isInited = false;

function init() {
    if (isInited) {
        return;
    }
    isInited = true;

    ...
}

$(document).ready(init);

window.onhashchange = function() {
    $(document).ready(init);
};

Answer 4

It's called the BF Cache and it's been around since FF 1.5

Bind to the pageshow event and event.persisted will tell you if its served from the cache.

http://msdn.microsoft.com/library/ie/dn265017(v=vs.85).aspx

https://developer.mozilla.org/en-US/docs/Using_Firefox_1.5_caching

Answer 5

I have been equally annoyed with this problem. Why is IE so frustratingly different?

I found that setting Cache-Control: no-cache in the HTML file wasn't helping. What helped was to actually set that in the response header.

In my case I'm drawing a Google chart and I need it to redraw whenever I visit the page (IE11 was even preventing the redraw of my chart when I refreshed the page manually!).

I'm using ASP.NET MVC and this code in my action method solves the problem.

Response.CacheControl = "no-cache";

Hope this helps.