We Keep Coding

Javascript/JQuery drop event not firing in Internet Explorer IE 11

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.

$("Iframe").contents() works on localhost but not online? [duplicate]

This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
jQuery/JavaScript: accessing contents of an iframe
If i run this on my localhost, it works fine, as long as the src if the iframe is on localhost aswell..
But as soon as i get it online, it doesent do a thing...
http://jsfiddle.net/WnwRc/9/
The goal right now is simply to alert the HTML that is loaded in to the iframe.

A security feature in browsers prevents you from accessing certain DOM objects inside iFrames whose document.domain property is different from the accessing iFrame.
If you're trying to do some web scraping or automation via an iFrame, I'm afraid that's not going to work very well.
Here's a quick link with tons of information for iFrame do's and don'ts:
http://softwareas.com/cross-domain-communication-with-iframes

Load Event doesn't bubble as properly as per jquery website
http://api.jquery.com/load-event/
Note: The .live() and .delegate() methods cannot be used to detect the load event of an iframe. The load event does not correctly bubble up the parent document and the event.target isn't set by Firefox, IE9 or Chrome, which is required to do event delegation.

window.open no longer works when called in the onunload event handler in IE9

In my web application, I launch a desktop application using a custom url protocol. For example: "fakeproto://" will launch "fakeproto.exe" on your desktop. If you don't know what I'm talking about, read this: Registering an Application to a URL Protocol
I needed a way, though, to make sure "fakeproto.exe" was installed on the user's PC before attempting to launch. It's a bit of a hack, but I got it to work for all the major browsers. IE presented the most problems and had a unique implementation.
In Javascript, I would first try to load the custom url protocol:
window.open('fakeproto://', '_self');
Before this, I actually defined the following onunload event handler:
window.onunload = function()
{
window.open('help.php', '_self');
}
So if the desktop didn't recognize the custom url protocol, IE would simply leave the current page and go to "webpage cannot be displayed". In this event, the onunload event handler would fire and open help.php instead.
This works great in IE7 & IE8, but once I upgraded to IE9, this no longer works? It goes to "webpage cannot be displayed" instead of help.php.
Using a debugger, the onunload event handler is firing and the code is being executed correctly, but for some reason the window.open call isn't working??? I disabled the pop-up blocker as well, to make sure it wasn't that. No luck.
Anyone have any ideas? Anyone hear of IE9 being more strict with window.open? Anyone know of any alternative solutions to the original problem?
BTW, I can get it to work if I open help.php to a new window.
window.onunload = function()
{
window.open('help.php', '_blank');
}
But this only works if any pop-up blockers are disabled. I would like to avoid using this solution.

Yes, IE9 blocks navigations in the onunload handler.

Bug with Chrome's localStorage implementation?

Further to this question, I'm getting a curious result when binding a function to the change event of the Storage object in Chrome 8.0.552.224.
The test:
<!DOCTYPE html>
<html>
<head>
<title>Chrome localStorage Test</title>
<script type="text/javascript" >
var handle_storage = function () {
alert('storage event');
};
window.addEventListener("storage", handle_storage, false);
</script>
</head>
<body>
<button id="add" onclick="localStorage.setItem('a','test')">Add</button>
<button id="clear" onclick="localStorage.clear()">Clear</button>
</body>
</html>
Open up the page in two Chrome windows, one window with two tabs,
Click the 'Add' button
When I do this I get an alert box displayed on on the second tab and on the second window but not on the tab that invoked the event (the I clicked on). As I understand it I should see three alert boxes (one for each tab opened).
Is this a bug? Is anyone else getting this behaviour? If not what version are you running? Or have I just got this all completely wrong?

Update and final conlusion
It turns out that the spec actually says that this is the desired behavior, therefore IE9's implementation is broken.
4.2 The sessionStorage attribute
When the setItem(), removeItem(), and clear() methods are called on a Storage object x ... if the methods did something, then in every HTMLDocument ... [that is] associated with the same storage area, other than x, a storage event must be fired....
So as we can see, the spec does do a really bad job at making it clear, that this is the specified behavior. That was the reason why Opera 10's implementation was broken and it's most likely also the reason why IE9's implementation is broken.
What do we learn from that? Always read every, single, word of the specification (especially if you're implementing the stuff...).
Old answer
As you said the basic behavior here is "Invoke on all but the current page".
There's an old Chrome Bug Report from last July.
As one can read there, Firefox has the same "issue". I've tested this with the latest nightly, still behaves the same way like in Chrome.
Another test in Opera 11 shows that this must be some kind spec'ed behavior, since Opera 11 does the exact same thing but Opera 10 did fire events on all windows / tabs. Sadly the official changelogs for Opera 11 do not state any change for this behavior.
Reading through the specification, nothing there states this behavior. The only thing I could find is:
The storage event is fired when a storage area changes, as described in the previous two sections (for session storage, for local storage).
When this happens, the user agent must queue a task to fire an event with the name storage, which does not bubble and is not cancelable, and which uses the StorageEvent interface, at each Window object whose Document object has a Storage object that is affected.
Note: This includes Document objects that are not fully active, but events fired on those are ignored by the event loop until the Document becomes fully active again.
Well, what does the Note mean?
From another specification:
A Document is said to be fully active when it is the active document of its browsing context, and either its browsing context is a top-level browsing context, or the Document through which that browsing context is nested is itself fully active.
Doesn't make sense? Yes. Does it help us in any way? No.
So we (in the JavaScript Chatroom) poked on #whatwg to see what all of this is about, so far there has been no response. I'll update my answer as soon as we get any response.
To conclude for now
Firefox, Chrome, Safari and Opera have the exact same behavior. That is, they do not fire on the tab / window that made the chance to localStorage.
But IE9 Beta behaves like Opera 10, so it fires on all tabs / windows.
Since the author of the localStorage spec works at Google in R&D, I hardly doubt Chrome would get this wrong. And since there are no Bugs on this over at Bugzilla and Opera changed the behavior in 11, it seems that this is the way it should work. Still no answer why it works this way and why IE9 behaves differently, but we're still waiting for a response from #whatwg.

Ivo Wetzel's answer for what is going wrong is correct.
I was having the same problem but managed to work around this limitation in the spec by manually creating and firing a StorageEvent in the tab that initiated the storage change (see StorageEvent#initStorageEvent).

JavaScript parent page redirection from iframe

I need to implement parent page redirection from iframe. I know that it is impossible to do in different domains due to browsers security.
However I found that links have target attribute and tried to use it in the following way:
someLink
It works fine if I click this link manually, but I couldn't find cross-browser solution to simulate it using JavaScript.
document.getElementById('testParentRedirect').click();
This works fine in IE, however Firefox and Safari don't know click function :).
I tried to work with jQuery, but for some reason they don't simulate click event for links.
(see following post)
I couldn't find any appropriate solution on Stack Overflow.
Maybe someone could help me in it. I will appreciate it. :)

You can do this in javascript to exit a frame:
window.top.location = "http://google.com";

You can try
top.location.replace( "http://google.com" );
in javascript to "escape" from the frame.
Edit: Using replace is slightly nicer, changed my answer to use that.