We Keep Coding

window.onbeforeunload listener not triggering on tab close in Firefox

The Problem
I have a function that should run on window.onbeforeunload. In Chrome, this works correctly and runs whenever a tab or window is closed or refreshed. In Firefox, however, it only runs on refresh, not close.
The Code
Here is an example:
var onStorageUpdate = function(){
var lastUnloaded = localStorage.getItem("LastUnloaded");
if(lastUnloaded === null){
$("div").text("Never stored");
}
else{
$("div").text(lastUnloaded);
}
};
onStorageUpdate();
window.addEventListener("beforeunload", function(){
var now = Date.now();
localStorage.setItem("LastUnloaded", now);
});
window.addEventListener("storage", function(){
onStorageUpdate();
});
Here is the order of events that should work in the above code:
On initial page load, attempt to get LastUnloaded from localStorage. If nothing is retrieved, show "Never Stored", otherwise show the value that was stored (should be a long integer timestamp)
Upon unloading a tab, updated LastUnloaded with the current timestamp. This is the part that doesn't seem to work in Firefox when closing a window.
Upon change in localStorage, update the DOM to show the timestamp
Demo
Here is a codepen of the example: http://codepen.io/jakelauer/full/NqRyqQ/
In order to test it, open the link in two different windows or tabs. You should notice that when you refresh either tab, both tabs update to show the same timestamp. In Chrome, you will notice that if you close one tab, the other tab will update its timestamp. In Firefox, you will notice that the timestamp does not get updated.
Any ideas? Thanks in advance!

I ended up just using onunload, which worked fine everywhere.

iOS Safari Mobile doesn't trigger pageshow firing only once

The iOS Safari doesnt't seem to trigger pageshow event in the following situation.
Lets say I have 3 pages
Page A : (has some code code on pageshow event)
Page B
Page C
User navigates from A -> B. Presses the back button. (pageshow triggers fine)
User then navigates to another page could be Page B or Page C. Then presses the back button again. (pageshow doesn't trigger)
On the contrary if the user minimizes and maximizes the window again or switches to another window and back (by pressing the middle button on iPhone) the pageshow event is triggered again.
Everything seems to work fine on Android
window.onpageshow = function(e) {
alert('hello');
}
Did anyone else face it? I spent hours on this thing and couldn't think of a workaround.
Any help would be greatly appreciated.

Hack : This is what worked for me
var myCustomEvent = (navigator.userAgent.match('iPhone') != null) ? 'popstate' : 'pageshow';
$(window).on(myCustomEvent, function(e) {
...
}
For some reason popstate triggers everytime when page state changes in iOS but not in Android.

Try using:
window.onpageshow = function(event) {
if (!event.persisted) {
alert("hello");
}
};
Persisted is false on initial page load, so you can check against it, and if it false, it is your first page load.

The popstate event doesn't seem to work any more, at least for me. I worked out some third-party script on my page was breaking this, but wasn't able to work out which one. I came up with this hack:
addEventListener('pageshow', () => {
history.replaceState({}, document.title, window.location.pathname);
// called on initial load and first back
});
addEventListener('popstate', () => {
// called on all back events
});

window.location.href causing animated gif loader to freeze in Firefox

I have a link which when clicked redirects the user to the same page except with additional parameters:
<a id="lnkExportToPDF" href="javascript:void(0)">Export</a>
$('#lnkExportToPDF').click(function (e) {
e.preventDefault();
window.location.href = path + 'users/export/' + parm1 + '/' + parm2;
});
On the server side I handle it by checking for "export" in the request path, and if it's found I write a PDF file to the response:
System.Web.HttpResponse response = System.Web.HttpContext.Current.Response;
response.Clear();
response.AddHeader("Content-Type", "application/pdf");
response.AddHeader("Content-Disposition", String.Format("attachment; filename=" + filename + ".pdf; size={0}", buffer.Length.ToString()));
response.BinaryWrite(buffer);
response.End();
Everything works and the user can download the file, but any additional actions by the user that uses the loader.gif which is on the page shows an unanimated loader.
What could be causing this to happen? Is there any way to refresh/reload the page/javascript after the response is complete?
edit: I've found a useful JS tool here: http://fgnass.github.io/spin.js/ but I'd prefer not to use it unless absolutely necessary
edit2: I also tried using a generic handler (.ashx) to handle the request (ie. changing the href to point to the handler), but as soon as the page redirects and the file is written, same thing happens
edit3: The problem is only happening in Firefox so far. I've tried Chrome and IE and the gif stays animated in those browsers. (latest versions of each)
edit4: If I use an iframe with the src as the image it solves the issue, but it's very hacky and the style of it looks different across all browsers with regards to centering/padding/margins.
edit5: Yeah. If I inspect the frozen gif with firebug it magically unfreezes itself.

I managed to recreate the problem in firefox and I really can't find a way to "unfreeze" the gif. When I added a completely different file after a download and that too was frozen I gave up with that approach.
What I did instead was to test different ways to trigger the download. I found no window.location solutions that worked, what did work though was this:
window.open(path + 'users/export/' + parm1 + '/' + parm2);
window.open opens a new tab and downloads the file through that instead of the current tab as window.location does. It will return to the current tab as soon as the download starts.
Edit
You could also use a hidden iframe:
var iframe = document.getElementById('iframe');
iframe.src = path + 'users/export/' + parm1 + '/' + parm2;

I confirm that I have the same behavior with firefox, and the first that come to my mind is to use SetTimeOut but still the same behavior, so on firefox for some reason, this window.location.href is also call the "Stop" on browser, that this cause the gif animation to stop.
So what I found and you can solve your issue, that this is not happends on simple links.
And if you change your code you can archive the same effect with a link.
So change this
$('#lnkExportToPDF').click(function (e) {
e.preventDefault();
window.location.href = "page.aspx";
});
to something like this
$('#lnkExportToPDF').attr("href", "page.aspx");
and you have the same results, and gif will still moving.
Here is the fiddle test.
On the test I add to move to paypal, because is slow moving and you can see the animation stop or not, also pp not let show on iframe, so on example you stay on example and not load the page.
When you click on this example, the issue is appears only on firefox !
http://jsfiddle.net/hn7S9/4/
One other issue that I think is that if you need to make your parametres to the next page on click, you probably need to redesign that and fix them before your click.
This is possible because for sure is not depends on the last click on the dynamic create link. So make the link with their parametres before the click.

You could try an asynchronous approach on the click to allow the browser to parse the event queue after the click has initiated:
$('#lnkExportToPDF').click(function (e) {
e.preventDefault();
setTimout(function() {
window.location.href = path + 'users/export/' + parm1 + '/' + parm2;
}, 20);
});

How about allowing the link to actually fire, but opening it in a new tab?
That shouldn't interrupt anything about the gif, and is semantically fine, other than I guess it would leave a tab open. You could get rid of the content-disposition, and allow the browser /user to decide what to do with it though.
<a id="lnkExportToPDF" target="_blank">Export</a>
$('#lnkExportToPDF').click(function (e) {
$(this).attr("href", path + 'users/export/' + parm1 + '/' + parm2);
});

Instead of setting the window.location.href, you can use a form with method="get" and submit it. This form could either be coded into your HTML or created dynamically. See this Answer:
https://stackoverflow.com/a/21742326/1614903

Here's my solution. It's faster and easier than any fix or workaround I've found. Just open the problem page in Chrome. Chrome has it's own problems, but this isn't one of them. Whenever I encounter a page full of gifs that causes Firefox to freeze, I just copy the URL, close the tab, open Chrome, and paste in the URL. I works every time! :o)

Prevent safari loading from cache when back button is clicked

Got an issue with safari loading old youtube videos when back button is clicked. I have tried adding onunload="" (mentioned here Preventing cache on back-button in Safari 5) to the body tag but it doesn't work in this case.
Is there any way to prevent safari loading from cache on a certain page?

Your problem is caused by back-forward cache. It is supposed to save complete state of page when user navigates away. When user navigates back with back button page can be loaded from cache very quickly. This is different from normal cache which only caches HTML code.
When page is loaded for bfcache onload event wont be triggered. Instead you can check the persisted property of the onpageshow event. It is set to false on initial page load. When page is loaded from bfcache it is set to true.
Kludgish solution is to force a reload when page is loaded from bfcache.
window.onpageshow = function(event) {
if (event.persisted) {
window.location.reload()
}
};
If you are using jQuery then do:
$(window).bind("pageshow", function(event) {
if (event.originalEvent.persisted) {
window.location.reload()
}
});

All of those answer are a bit of the hack. In modern browsers (safari) only on onpageshow solution work,
window.onpageshow = function (event) {
if (event.persisted) {
window.location.reload();
}
};
but on slow devices sometimes you will see for a split second previous cached view before it will be reloaded. Proper way to deal with this problem is to set properly Cache-Control on the server response to one bellow
'Cache-Control', 'no-cache, max-age=0, must-revalidate, no-store'

Yes the Safari browser does not handle back/foreward button cache the same like Firefox and Chrome does. Specially iframes like vimeo or youtube videos are cached hardly although there is a new iframe.src.
I found three ways to handle this. Choose the best for your case.
Solutions tested on Firefox 53 and Safari 10.1
1. Detect if user is using the back/foreward button, then reload whole page or reload only the cached iframes by replacing the src
if (!!window.performance && window.performance.navigation.type === 2) {
// value 2 means "The page was accessed by navigating into the history"
console.log('Reloading');
//window.location.reload(); // reload whole page
$('iframe').attr('src', function (i, val) { return val; }); // reload only iframes
}
2. reload whole page if page is cached
window.onpageshow = function (event) {
if (event.persisted) {
window.location.reload();
}
};
3. remove the page from history so users can't visit the page again by back/forward buttons
$(function () {
//replace() does not keep the originating page in the session history,
document.location.replace("/Exercises#nocache"); // clear the last entry in the history and redirect to new url
});

You can use an anchor, and watch the value of the document's location href;
Start off with http://acme.co/, append something to the location, like '#b';
So, now your URL is http://acme.co/#b, when a person hits the back button, it goes back to http://acme.co, and the interval check function sees the lack of the hash tag we set, clears the interval, and loads the referring URL with a time-stamp appended to it.
There are some side-effects, but I'll leave you to figure those out ;)
<script>
document.location.hash = "#b";
var referrer = document.referrer;
// setup an interval to watch for the removal of the hash tag
var hashcheck = setInterval(function(){
if(document.location.hash!="#b") {
// clear the interval
clearInterval(hashCheck);
var ticks = new Date().getTime();
// load the referring page with a timestamp at the end to avoid caching
document.location.href.replace(referrer+'?'+ticks);
}
},100);
</script>
This is untested but it should work with minimal tweaking.

The behavior is related to Safari's Back/Forward cache. You can learn about it on the relevant Apple documentation: http://web.archive.org/web/20070612072521/http://developer.apple.com/internet/safari/faq.html#anchor5
Apple's own fix suggestion is to add an empty iframe on your page:
<iframe style="height:0px;width:0px;visibility:hidden" src="about:blank">
this frame prevents back forward cache
</iframe>
(The previous accepted answer seems valid too, just wanted to chip in documentation and another potential fix)

I had the same issue with using 3 different anchor links to the next page. When coming back from the next page and choosing a different anchor the link did not change.
so I had
House 1
View House 2
View House 3
Changed to
House 1
View House 2
View House 3
Also used for safety:
// Javascript
window.onpageshow = function(event) {
if (event.persisted) {
window.location.reload()
}
};
// JQuery
$(window).bind("pageshow", function(event) {
if (event.originalEvent.persisted) {
window.location.reload()
}
});
None of the solutions found online to unload, reload and reload(true) singularily didn't work. Hope this helps someone with the same situation.

First of all insert field in your code:
<input id="reloadValue" type="hidden" name="reloadValue" value="" />
then run jQuery:
jQuery(document).ready(function()
{
var d = new Date();
d = d.getTime();
if (jQuery('#reloadValue').val().length == 0)
{
jQuery('#reloadValue').val(d);
jQuery('body').show();
}
else
{
jQuery('#reloadValue').val('');
location.reload();
}
});

There are many ways to disable the bfcache. The easiest one is to set an 'unload' handler. I think it was a huge mistake to make 'unload' and 'beforeunload' handlers disable the bfcache, but that's what they did (if you want to have one of those handlers and still make the bfcache work, you can remove the beforeunload handler inside the beforeunload handler).
window.addEventListener('unload', function() {})
Read more here:
https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/1.5/Using_Firefox_1.5_caching

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

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>
Click Me!
</body></html>
1.html
<html><body>
<p>Go BACK!</p>
</body></html>

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>
Click Me!
</body></html>
Source:
http://www.firefoxanswer.com/firefox/672-firefoxanswer.html (Archived Version)

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!');
};

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");
}
});

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"); });

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>
Click Me!
</body></html>

As far as i know Firefox does not fire onLoad event on back.
It should trigger onFocus instead based from this link here.

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...
};

for some cases like ajax operations url change listener can be used
$(window).on('hashchange', function() {
....
});