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/
Related
I have added code to change web page color on beforeunload event:
window.onbeforeunload = function (){
$('.navbar-collapse').css({background: 'blue'});
console.log("Hello unload");
return null;
}
This code works properly on Chrome and Firefox but it doesn't work on Safari browser.
However, when I debug this code in Safari, when stepping over each line of code in the callback function, id DOES changes background color.
When I navigate by clicking on an url on page and then click back button on browser, the background color is changed.
Any idea?
window.onbeforenload is "magic" in the sense that it is special and more and more browsers are restricting what it can do.
Some browsers will let you display a custom message, other browers are free to ignore this event entirely.
In short: Don't try to do anything but return a null or non-null value and hope for the best. It is out of your hands.
You might want to see this answer too: window.onbeforeunload and window.onunload is not working in Firefox , Safari , Opera?
I'm dragging and dropping images from a different browser tab into the tab for my web page. My event handlers for the "drop" event are working in every other desktop browser except Internet Explorer 11.
IE just navigates away to the URL of the image I dropped, rather than firing the "drop" event and letting my JS code do what it wants with it (as happens in Chrome, Firefox, Opera and Safari, on Windows 7). Code is below. Note none of the alerts listed in the code fire.
I even followed the advice given on Microsoft's page here: https://msdn.microsoft.com/en-us/library/ms536929(v=vs.85).aspx
regarding cancelling the default action of "dragenter" and "specifying window.event.returnValue=false in both the ondragenter and ondragover event handlers" (note: other browsers didn't require me to have a dragenter event handler)
$(window).on("dragenter", function(event) {
alert('drag enter');
event.returnValue = false;
event.preventDefault();
event.stopPropagation();
});
$(window).on("dragover", function(event) {
alert('drag over');
event.returnValue = false;
event.preventDefault();
event.stopPropagation();
});
$(window).on("dragleave", function(event) {
alert('drag leave');
event.preventDefault();
event.stopPropagation();
});
$(window).on("drop", function(event) {
alert('drop');
event.preventDefault();
event.stopPropagation();
var imageSrc = $(event.originalEvent.dataTransfer.getData('text/html'))
.filter(function(i, elm){return $(elm).is('img');}).attr('src');
// Now do something with the imageSrc URL:
});
Many thanks for any suggestions!
It is working fine in IE Browser Version:11.0.40 for jQuery 2.2.4 version.
Please check your jQuery version
Note: for me event has been fired for two times when dragging image from desktop to IE 11 browser.
Please find Demo link.
Edit:
Interesting what I've got here (S.O question/answer), they had a similar problem dragging between two Internet Explorer 11 windows, on the same domain. So one more reason, if they are from different domains. He quotes:
so far I understood that this will work on Windows 10 MS browsers with
at least 1607 as version
First, this is by no means intended to be an answer to this question, it merely serves as a group of points that may help build a final answer to this puzzling problem
Two cases scenario
On the same domain
Tested when both pages are on localhost, Those events has fired normally :
you will have to change getData('text/html') to getData('text') because IE support only that, 'URL' or files
so you need to set setData() from the original page accordingly
(Generally, if the dragged markup is an image without any links, you're fine the getData('text') gives you the attribute src of the image)
On different domains
Here is the part where this is not much of an answer, the following points have been tried and are given here to be retested, tweaked or expanded in order to find a solution. As a final thought that I'm putting here first: may be this is not possible, because as you may already know, dragged markup can have inline scripts, making the target vulnerable to XSS attacks. It's not very unlikely that hackers have tried to make it happen (roughly as I'm doing right know) and each time Microsoft has counteract it.
As the original poster pointed out the use of returnValue=false is pointless. I've tried it on the original event event.originalEvent and with event as a window's event and as the handler parameter.
You may think since I've mention domain that this is a cross domain issue (very legitimate) here's what I've tried in PHP:
header("Access-Control-Allow-Origin: *");
After IE had been known for been vulnerable to XSS attacks, it may have taken drastic measures against it in IE 11, so reverting to a previous version's behaviour of it, IE9 for instance :
header('X-UA-Compatible: IE=EmulateIE9');
header('X-UA-Compatible: IE=9');
N.B The following point is not intended to be a viable solution (at least not from a developer's perspective) it is an attempt to narrow down the possibilities of the origin of the problem
You may want to try Internet Explorer's :
internet options>Custom level...-->miscellaneous--> under the label 'allow the dragging of content between separate windows' --> check enable
Or Internet Explorer security zones registry entries for advanced users or using this reference
Notice that for the purpose of testing you can make cross domain dragging between IE and Firefox/Chrome back and forth with DataTransfer behaving roughly as between two IEs on the same domain.
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
my script reads something like this:
$(window).bind('popstate', function() {
//some code
//few more lines of code
});
This function works perfectly as intended in Chrome and Safari browsers. But Firefox for some reason ignores this function and does not work as intended.
Instead of using:
$(window).bind('popstate', function() {
//some code
//few more lines of code
});
You can use:
window.onpopstate = function() {
//some code
//few more lines of code
}
As firefox is using W3C defined rules for history API, so you have to use this for firefox and it works in chrome, safari and other browsers as well.
Note that just calling history.pushState() or history.replaceState()
won't trigger a popstate event. The popstate event is only triggered
by doing a browser action such as a click on the back button (or
calling history.back() in JavaScript).
Browsers tend to handle the popstate event differently on page load.
Chrome and Safari always emit a popstate event on page load, but
Firefox doesn't.
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/popstate
Are you saying Chrome and Safari fire the event on page load or when the browser's back button is clicked? If the former, it's because Chrome/Safari are out of compliance with the HTML5 specs => the event should never be fired on page load. Up-vote https://code.google.com/p/chromium/issues/detail?id=63040 to get Google to fix this.
Please do Check that if you have coded window.load() more than once OR have called .onload() more than one time. This probably may work for IE but not for Chrome and fireFox.
Does onHashChange or hashChange work in Safari? I tested it with Safari 4.0.4 on Windows 7 and it doesn't work for me.
If it doesn't work, is there any solution to track if the hash has changed?
In our app we poll to check for changes:
$b.hashCheck = setInterval(
function(){
if ( window.location.hash !== $b.C.current_hash){
$b.C.current_hash = window.location.hash;
//call the on change action here
}
},$b.C.hashCheckDelay
);
$b is the global object we use for our namespace and hashCheckDelay was empirically set at 120ms.While it looks a bit sad to do this kind of process, there isn't any performance issue on any browser we tested.
In Safari 4.0.4 it's not working yet but in the latest one works fine. And I didn't find any acceptable solutions to track if the hash has changed for those browsers which don't support onHashChange.