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.
Related
I'm using Google Maps API in my react app. I've added a custom context menu on the maps on the right click button handler. It works absolutely fine on all browsers on Mac. Works fine on IE and Edge on Windows except for Google Chrome and Mozilla Firefox (on Windows OS) where apart from displaying the custom menu, the actual browser context menu also appears.
Here's a jsfiddle which contains a sample code which behaves similarly to how my code works.
Please check the above fiddle on Windows in different browsers and on right clicking the maps, you will see that on Chrome and Firefox, two menu appears and on Edge only the custom one (which is the expected behavior and this also works fine on Mac).
var ContextMenu = document.getElementById("my-context-menu");
google.maps.event.addListener(map, 'rightclick', function (ev) {
ShowContextMenuGoolge(ContextMenu, ev);
/** this stop NOT stopping DOM 'context-menu' event from firing */
ev.stop();
});
google.maps.event.addListener(map, 'click', function () {
HideContextMenuGoolge(ContextMenu);
});
}
Expected behavior (Screenshot from Chrome in Mac):
What actually is happening (Screenshot from Chrome in Windows):
I have tested this solution on both FireFox and Google Chrome so just add this piece of code at the very top of your js file:
window.onload = (function(){
document.addEventListener("mouseup", function(evt){
console.log(evt)
evt.preventDefault();
evt.stopPropagation();
});
document.addEventListener("contextmenu", function(evt){
console.log(evt);
evt.preventDefault();
evt.stopPropagation();
});
})();
Also remove the ev.stop() method as it won't do anything. See below.
JavaScript within the browser is event driven, meaning that JavaScript
responds to interactions by generating events, and expects a program
to listen to interesting events. User events (such as "click" mouse events) are propagated from the DOM to the Maps JavaScript API. These events are separate and distinct from standard DOM events.
See this link for the above reference
Also note that disabling the right-click event via contextmenu in the browser may not be the ideal solution. I suggest additional resarch on your side.
I just spent half a day trying to solve this exact same problem, and the solution posted here and in several other threads on this issue just wouldn't work for me. Here's what did:
// Add a listener to the Intelligence Bounds to serve a context menu
google.maps.event.addListener(myPolygon, 'rightclick', (evt) => {
if (evt.vertex && myPolygon.getPath().getLength() > 4) { // Don't let them delete a node if it would turn us into a line
// Set timeout is used only because it solves the issue of Windows Chrome/Firefox browser context menu overlaying our own
setTimeout(this.onVertexRightclick, 0, evt.vertex, this)
}
});
I honestly don't understand why this works but I'm glad someone posted it. Wrapping the handling of the event in a setTimeout() set to zero ms was the only fix that worked.
All the other fixes I've seen relate to the 3.0 maps API and were posted ~ 2018. I'm using the newer Angular widget that came out in 2019 and is supposed to simplify usage and just wrap the API to my understanding, so perhaps that's the difference in this case.
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
I have a web application in which I have hooked mouse up and mouse down events; I use them for selection and manipulation of the graphical language for which my application is an editor. To prevent the right-click/context menu supplied by Firefox from showing up, I've placed:
if (evt.preventDefault) {
evt.preventDefault();
}
at the top of each of my mouse up and mouse down event handlers. I don't want to return false; I actually want the event to propagate.
On the Mac, the right-click menu doesn't show up; this is what I expect. On Windows, however, it stubbornly appears, even though Firebug confirms that my call to "preventDefault" is occurring and likewise "defaultPrevented" gets set to true.
Any idea what gives? Has anyone else run across this problem? I'm running Firefox 6.0.2 on both the Mac and Windows.
[Update: more recent versions of Firefox yielded consistent results on Mac and Windows: the context menu failed to be suppressed on both platforms.]
Okay. After putting this aside and returning to it several times, I finally found the solution.
Attempting to deal with the appearance of the context menu in the various mouse listeners appears to be fundamentally flawed. Instead, thanks to code I found here, I was put on the scent of the contextmenu event. That event appears to be the right way to handle things, although the code actually posted on that site didn't do the trick — merely calling "stopPropagation" and returning false was insufficient.
The following worked for me:
element.addEventListener('contextmenu', function(evt) {
evt.preventDefault();
}, false);
This has been tested with Firefox 10.0 on a Mac and Firefox 9.0.1 and 10.0 on Windows 7.
This option is removed in Mozilla's 23rd version.
Go to Tools > Options.
Go to the Content tab.
Click Advanced button next to Enable JavaScript option.
Disable or replace context menus. Check this box and it will magically work again.
There is no way to get around this setting in JavaScript.
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
I'm currently working on a jQuery plugin that tracks a visitors mouse behavior. Movements, clicks, scrolling and resizing are all recorded and sent, via Ajax, to a location where this data is parsed and stored.
Originally, the data is sent to a script when the user leaves the page. By 'leaves' I'm referring to refreshing, going back and forth though history, closing the window/tab and going to a different address.
The solution works in all browsers EXCEPT for Opera. I'm using jQuery's 'unload' event which isn't supported by Opera at all. Neither is onbeforeunload or onunload.
The question is, how do I implement this kind of functionality for Opera browsers?
One solution I had was to make special use of a 'polling' feature I created. This feature allows you to specify an interval which pushes the content to the server every 'x' seconds. Setting this to 1 second specifically for Opera browsers would probably solve this issue, but it's an awful amount of overhead and the requests aren't always completed in sequence, etc ...
Any suggestions or am I only stuck with the above option?
Thanks!
I suppose I could just link you guys to the plugin source. http://www.thedrunkenepic.com/junk/jquery.mousalytics.js
Regarding the code linked above, adding:
if(window.opera)
{
options.interval = 1;
}
On line 89 works great. My only concern is overhead, so I'm still looking for a more elegant solution.
According to http://bytes.com/topic/javascript/insights/799229-browser-quirk-onload-onunload-do-not-fire-back-forward-refresh-opera, Opera never really fires onload / onunload events, so functionality like this isn't possible without hacks.
http://dev.opera.com/articles/view/efficient-javascript/?page=4 seems to confirm this, and basically states that opera tries to maintain the state of the page across requests.
On further investgation, http://unitehowto.com/Onunload indicates that it might be possible with opera.io.webserver.addEventListener('_close', onunload, false); (where onunload is a previously defined function), however it also indicates that this functionality is not consistent across all versions of opera, and might not work at all.
I think that your best option is probably to use the polling option for Opera, or possibly use a server-side check for the current page and where it falls in the history queue.
Does adding this line of JavaScript work for you?
history.navigationMode = 'compatible';
Source: http://www.opera.com/support/kb/view/827/
I've had the same problem and this saved my day:
if( typeof(opera) != 'undefined' )
{
opera.setOverrideHistoryNavigationMode( 'compatible' );
history.navigationMode = 'compatible';
}
More info about this problem can be found at: http://www.opera.com/support/kb/view/827/