We Keep Coding

IE not firing popstate when hashchange happens

I have page that is doing the routing on clientside, using history API & push/popstate. Which works just fine on all the modern browsers. (search engines will be supported by node.js prerenderer)
However, I recently bumped into issue where IE doesn't fire popstate on hashchange while, while pushstate with urls works just fine, including IE11.
For example, like so...
$(document).on('click', 'a', function(e) {
e.preventDefault();
History.pushState({}, '', $(this).attr('href'));
});
...which correctly fires...
$(window).on('popstate', function() {
console.log('url changed');
});
According the W3C spec, the hashchange should fire popstate as it's changing the current history. However, when I add in hash links (<a href="#hashchange">...), clicking that on IE, nothing fires. :/
I wouldn't want to do IE detecting (as nowadays there are so many browsers which might fall in to the same pit of doom), rather than using feature detection. However, as history (popstate/pushstate) works just fine the rest of the way I can't even detect the issue on missing push/popstate...
if(!window.history || !window.history.pushState) { ...
... and use the hashchange instead. :/
Any thoughts?
PS. As a bonus, using jquery.history.js (jquery wrapped version of history.js) with hashtag url blows the whole thing up.
http://localhost/routetest/index.html#/page1/1234
becomes
http://localhost/page1/1234
... ??? :/

This is a known issue in IE11 and all Internet Explorer browsers before Edge.
See this link https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/3740423/. The Microsoft response is the last post in this issue report, and notes the newest version that is working.
All versions of IE will display this behavior, and hacking/monkey-patching the correct behavior back into the event framework is probably the only way to make it work reliably. This means you will likely need IE specific logic if you want to implement it yourself.

Try using a polyfill for History API for better support https://github.com/browserstate/history.js

In IE 10 and 11 the popstate event will only be fired for a history item after the state has been set with history.pushState or replaceState, including when it is set to null, and only when traversing between two items that have had state set. Therefore, it is necessary to set the state for a new history item in the hashchange event. Once the state is set, the popstate event will fire when the user navigates through the browser history.
https://developer.mozilla.org/en-US/docs/Web/API/History

bind is not working in safari 5.1.1

I'm using safari 5.1.1 in my system and my application is also running in safari 5.1.1. In my application i'm using window resize event with bind method. Its working fine all other browsers like ie, chrome,firefox but it doesn't work in safari 5.1.1 and less. whenever its run it will through an exception as '"undefined" is not a function({....}.bind(this);...'.
I have searched more about this issue but i din't found any solutions to recover this issue.
$(window).resize(function () {
alert("resized");
...My code goes 'this' here....
}.bind(this));
Is there any way to resolve this issue?
Thanks,
KarthiK

The error most likely comes from .bind(this). As you see in the MDN docs about Function.prototype.bind, safari supports bind in versions >= 5.1.4.
You can use jQuery.proxy instead.
var resizeHandler = function() { alert('resized'); };
$(window).resize($.proxy(resizeHandler, this));
Did not test the example but it should look like this.

History.js onstatechange in IE7 does not work

I integrated History.js and this piece of code runs on URL change:
History.Adapter.bind(window,'statechange',function(){
var State = History.getState();
alert(State.url)
showPage(State.url);
});
It works well in all browsers except IE7 (compatibility mode of IE8). I thought History.js would handle this.
Is it true that IE7 does not understand onStateChange event? What window event can be used for this case?

From the notes on compatibility it states:
MSIE 6 and 7 sometimes do not apply a hash even it was told to (requiring a second call to the apply function)
https://github.com/browserstate/History.js/

window.onbeforeunload not working on the iPad?

Does anyone know if the onbeforeunload event is supported on the iPad and/or if there's a different way to use it?
I've tried pretty much everything, and it seems like the onbeforeunload event is never triggered on the iPad (Safari browser).
Specifically, this is what I've tried:
window.onbeforeunload = function(event) { event.returnValue = 'test'; }
window.onbeforeunload = function(event) { return 'test'; }
(both of the above together)
window.onbeforeunload = function(event) { alert('test')'; }
(all of the above functions but inside <body onbeforeunload="...">
All of these work on FF and Safari on the PC, but not on the iPad.
Also, I've done the following just after loading the page:
alert('onbeforeunload' in window);
alert(typeof window.onbeforeunload);
alert(window.onbeforeunload);
Respectively, the results are:
true
object
null
So, the browser does have the property, but for some reason it doesn't get fired.
The ways I try to navigate away from the page are by clicking the back and forward buttons, by doing a google search in the top bar, by changing location in the address bar, and by clicking on a bookmark.
Does anyone have any idea about what's going on? I'd greatly appreciate any input.
Thanks

This bit of JavaScript works for me on Safari and Chrome on ipad and iphone, as well as desktop/laptop/other browsers:
var isOnIOS = navigator.userAgent.match(/iPad/i)|| navigator.userAgent.match(/iPhone/i);
var eventName = isOnIOS ? "pagehide" : "beforeunload";
window.addEventListener(eventName, function (event) {
window.event.cancelBubble = true; // Don't know if this works on iOS but it might!
...
} );

I have found that the onunload() event does fire. It's behavior is somewhat odd; whatever you have in your callback function attached to the event is actually run after the new page has loaded in the background (You can't tell it's loaded yet, but server logging will show that it has).
More oddly, if you have a confirm() call in your onunload(), and the user has clicked a link to go somewhere else, you are in business. If, however, the user closes the iPad Safari browser tab, the onunload() event will fire, but your confirm() will have an implicit cancel as response.

Only Apple would know for sure, but my guess is that they purposely did not enable that functionality in mobile Safari because it is most often used by shady characters to get you to stay on their site or pop up lots of porn/advertising windows.

There's a known bug in WebKit with onbeforeunload. I believe it's fixed in the latest beta of Chrome 5, but it's quite possible the iPad's browser is made from a version of WebKit that doesn't have the fix.
Related Chrome bug report.

beforeunload event is not supported by Mobile Safari. You can see the list of all supported events here: Handling Events Apple documentation
And the beforeunload is not in the list!

https://code.google.com/p/chromium/issues/detail?id=97035
see hear.
alerts are no longer allowed during page dismissal events (beforeunload, unload, pagehide).
I think alerts, prompt, confirm, and other actions like these are also no longer allowed.

Here's a solution that should work on all modern browsers:
var unloaded = false;
window.addEventListener("beforeunload", function(e)
{
if (unloaded)
return;
unloaded = true;
console.log("beforeUnload");
});
window.addEventListener("visibilitychange", function(e)
{
if (document.visibilityState == 'hidden')
{
if (unloaded)
return;
unloaded = true;
console.log("beforeUnload");
}
});
Mobile browsers don't tend to not support beforeunload because the browser can go into the background without unloading the page, then be killed by the operating system at any time.
Most desktop browser contain a bug that causes visibilityState to not get called when the document unloads. See: here.
Therefore, it's important to include both events to cover all scenarios.
NB
I have used console.log instead of alert in my example because alert will get blocked by some browsers when called from beforeunload or visibilitychange.

If you just need to know if the page has been left you can use document.unload. It works fine in ios browsers. If you see on Apple documentation you'll find that it's deprecated and they recommend to use document.pagehide

onbeforeunload in Opera

I'm using the code that netadictos posted to the question here. All I want to do is to display a warning when a user is navigating away from or closing a window/tab.
The code that netadictos posted seems to work fine in IE7, FF 3.0.5, Safari 3.2.1, and Chrome but it doesn't work in Opera v9.63. Does anyone know of way of doing the same thing in Opera?
Thx, Trev

Opera does not support window.onbeforeunload at the moment. It will be supported in some future version, but has not been a sufficiently high priority to get implemented as of Opera 11.

onbeforeunload is now supported in Opera 15 based on the WebKit engine but not in any prior versions based on Presto.

Have you tried this?
history.navigationMode = 'compatible';
Reference, found via this page
I haven't actually tried it myself, but it looks promising.

Mobile Safari (iPhone/iPad) also doesn't support onbeforeunload, and I strongly suspect it is not likely to.
For detecting back/forward navigation there may be workarounds e.g. see Is there an alternative method to use onbeforeunload in mobile safari?.