I need to capture the event triggered by dragging and dropping a bookmark onto the window, preferably in all browsers. What I actually need is the target url of the bookmark. onbeforeunload does get triggered, but the event has no information about the target URL and I can't stop the page from loading it either. mouseup also does not work.
The FileReader API seems viable, but I'm not sure whether it's appropriate. Ideally this would also work in at least IE9 (which does not support FileReader).
I have a solution to part one of this problem, but I myself would like some help with the second part of it, so if this serves as a bump for your question it'd be much appreciated.
NOTE: Most of this is based off of my personal experience, so I'll make notes about compatibility before we get too far in.
The drop event is supported on Microsoft Edge 12+, and has a field, dataTransfer, that contains information about the element being dragged/dropped. This field was added to IE in is always null, and for that reason I won't be talking about a solution I found for it. From the timing of your post, it seems like you're using the latest Microsoft browser, which means that the features I talk about below will be supported.
The first event you'll want to take a look at is drop. This event, fairly logically, is an event that is fired when you drop an element onto a page, be it a file, another element, or in our case, a bookmark.
The second event, rather confusingly, is dragover. For some unknown reason, suppressing default behavior of the drop event on its own does not seem to completely negate the effect of going to a new webpage, instead redirecting me (using Chrome 94) to about:blank#blocked in a new tab, which might interfere with UX.
The files attribute of dataTransfer for the drop event usually contains the information about the data that is being transferred, and as I have experimented with, I've gotten this data from it:
{
items: DataTransferItemList {0: DataTransferItem {'kind': 'string', 'type': 'text/plain'}, 1: DataTransferItem {'kind': 'string', 'type': 'text/uri-list'}, length: 2},
types: ['text/plain', 'text/uri-list'],
files: FileList {length: 0}
}
I'm rather frustrated by the fact that files contains no data, and it's currently got me stuck to a point where I can't get any further. I'll see if I remember to post back here when/if it gets fixed, but until then, there's another thing I'd like to point out.
On Windows computers, internet shortcuts are actually small files with the .url extension. So, it's possible to obtain both a name for a site and its address if the user simply drags in a shortcut from their homepage. My code for getting the data is below.
element.addEventListener('drag', function(event)) {
event.preventDefault();
// in case you haven't put this in already; having multiple has
// the same effect as one
let shortcutFile = event.dataTransfer.files[0];
// This assumes the user is only dragging a single file, but it can be
// expanded to others by simply detecting the extension of the file.
let fileName = shortcutFile.name;
let fileLines = fileContent.split('\n');
// the last line of the file has a pattern that looks like this:
// URL=<url to site>
// this is what i'm going to be using to get the address.
//
// the better solution to the first index below would be to use
// Array.prototype.at(-1), however doing so would require a polyfill
// on all versions of Opera, IE, and Safari, not to mention that even somewhat
// recent browsers don't have this method implemented.
let siteUrl = fileLines[fileLines.length - 1].match(/(?<=URL=)/)[0];
// going to use one of my favorite JS features here: object destructuring!
// it's not supported in some older browsers, or in IE at all, but it's a VERY
// cool feature nonetheless, so I use it when i really shouldn't a lot of the time
//
// i know stuff is supposed to be cross-compatible but what's the point
// in browsers getting new APIs/interfaces like this if you don't use
// them?
return {fileName, siteUrl};
// oh yeah explanation of how it works
// it's basically the same thing as saying {fileName: fileName, siteUrl: siteUrl}
// looks very nice right?
}
Hope this information and workaround helps, and that the exact issue we both have gets resolved!
I found the solution! You have to use this method to get the actual URL: DataTransfer.getData(). Try putting
console.log(e.dataTransfer.getData("text/plain"));
into your "drop" event - it shows the URL for both Firefox and Chrome.
Related
The following piece of code, works correctly in Firefox and Chrome, but it gives me a headache in IE.
var anotherDiv= document.getElementById("anotherDiv");
var destination = document.getElementById("mySourceDiv");
destination.appendChild(anotherDiv);
I'm trying to get a Div element and place it inside another div.
I get an error message (in the debug console in IE) similar to "interface not supported", and points me to the appendChild line.
What I've seen is that the type of the destination variable is an object rather then a DOM element.
What can I do to append the anotherDiv to mySourceDiv?
I'm trying this in IE 8.
You probably will need something like an importNode, there are various cross browser solutions around. The issue is that each node has a corresponding document object on it, in IE and so called security doesn't play nice moving things from one document to another.
So, essentially it's doing a deep clone, but the difference between using cloneNode is that cloneNode also sets the document which you don't want.
This might get you going in the right direction:
IE support for DOM importNode
I'd recommend using a library designed to sort through the browser incompatibilities for you. I've personally found jQuery to be quite good. jQuery has an append function.
I'm trying to debug some JavaScript, I want to find out what code gets executed when I hover over a certain div element (I've got no idea which bit of code, because there's no direct 'onmouseover' - I think there's a jQuery selector in place somewhere?).
Usually I'd use the "Break All" / "Break On Next" facility provided by Developer Tools / Firebug, but my problem is that other code (tickers, mouse movement listeners etc.) immediately gets caught instead.
What I'd like to do is tell the debugger to ignore certain JavaScript files or individual lines, so that it won't stop on code I'm not interested in or have ruled out. Is there any way to achieve that in IE (spit, spit!) - or could you suggest a better approach?
In FireFox this feature is called "Black boxing" and will be available with FireFox 25. It let's do exactly what you where looking for.
This feature was also introduced to Chrome (v30+) although it's tougher to find/configure. It's called "skip through sources with particular names" and Collin Miller did an excellent job in describing how to configure it.
Normally I'm for putting answers and howtos here instead of links but it would just end in me copying Collin's post.
Looks like you're looking for Visual Event.
You might want to take a look at Paul Irish's Re-Introduction to the Chrome Developer Tools, in particular the Timeline section (starts around 15 minutes into the video.)
You can start recording all javascript events - function executions (with source lines etc) and debug based on what events fired. There are other really handy debugging tools hiding in that google IO talk that can help you solve this problem as well.
If you're pretty sure it's a jQuery event handler you can try to poke around with the jQuery events.
This will overwrite all the click handlers (replace with the type you're interested in) and log out something before each event handler is called:
var elem = document.body; // replace with your div
// wrap all click events:
$.each($._data(elem).events.click, function(i, v) {
var h = v.handler;
v.handler = function() {
// or use 'alert' or something here if no Dev Tools
console.log('calling event: '+ i);
console.log('event handler src: '+ h.toString());
h.apply(h, arguments);
};
})
Then try calling the event type directly through jQuery to rule out that type:
$('#your_div').click()
You can use JavaScript Deobfuscator extension in Firefox: https://addons.mozilla.org/addon/javascript-deobfuscator/. It uses the same debugging API as Firebug but presents the results differently.
In the "Executed scripts" tab it will show you all code that is running. If some unrelated code is executing as well it is usually easy enough to skip. But you can also tweak the default filters to limit the amount of code being displayed.
If using are using IE 7.0 onwards, you should have developer toolbar from where you can debug. Just use breakpoint where you need, rest of the code will not stop.
Alternatavely you can define other applications like Interdev/ Visual Studio.net for debugging purpose too.
I can add or remove an event handler for a DOM node. Is it possible to find out all the registered events handlers of a given DOM node? I am referring to straight Javascript meaning no frameworks or toolkits like jQuery, dojo, Prototype, GWT, etc. If the answer is no, any reason why? Security issues?
I know this is an old question, but just in case, for chrome you can use getEventListeners
getEventListeners function
as mentioned here:
https://stackoverflow.com/a/17466308/538752
DOM Level 3 specifies eventListenerList - however, I'm not aware of any DOM implementation which supports this - or any other reliable way to list the event listeners. It seems to have been an oversight to this point.
This works for Chrome/Safari console:
getEventListeners(document.getElementByID('myElementId'));
Visual Event can show you which events are registered, but it only works with DOM level 0 attached events; the W3C level 2 implementation as well as the Internet Explorer proprietary method are not supported and/or cannot be retrieved.
If your interest is to discover some event, in order to disable it - I came here because of that - I recommend to use the Firebug extension, with Mozilla Firefox. Selecting the part of the document, you are interested in, look at the right panel, the Events tab: you will see all events, and can even disable them.
Also, in Google Chrome, please select the element and notice the number, it will show you $0 or any other number.
Then in console, type this code and press enter.
getEventListeners($0)
and then you will see the result. Please see the image below for more elaboration.
I faced the same problem, landed here, and didn't find an useful answer.
In case you can execute script before addEventListener calls from other parties, you might do something really dirty like:
var obj = something; // Your DOM element you want to watch
var beforeAddEvent = obj.addEventListener;
obj.addEventListener = function() {
// Do something with arguments here (like storing in an array)
// arguments[0]: event name
// arguments[1]: Listener function
// arguments[3]: eventual options passed
// If you don't call this, the event listener won't even be attached, it might be also useful in some case
beforeAddEvent.apply(obj, arguments);
};
Our site makes use of FreeTextBox, a web-based, rich-text editor. In IE, but in not Firefox, if a user types in something like:
someone#blah
IE automatically creates a mailto hyperlink. I have tested this with other text editors out there and the story is the same with all of them.
Can I override this browser behavior somehow from within my application?
This has to do with the MSHTML editor, which (I'm guessing all) Windows browsers use to instantiate rich text editors. There's a setting called IDM_AUTOURLDETECT_MODE that lets you decide if the autolinking will take place, and the default is true (other browsers apparently set it to false on instantiation, hence no autolinking in Firefox.)
Unfortunately, until recently Microsoft didn't have a mapping from the command ID to a command identifier string, so the function wasn't accessible via Javascript prior to IE9.
I just tried it out in IE9 and can confirm that, for that version and presumably all future ones, you can override the feature by calling
document.execCommand("AutoUrlDetect", false, false);
Note that it's IE9+ only, so you're still stuck for previous versions, and that you'll want to wait until the DOM is loaded before you call it and have some error handling around it, etc, etc.
There's a good summary of the original issue here, and a discussion of the fix in the minor change list here.
Last week we released Omniture's analytics code onto a large volume of web sites after tinkering and testing for the last week or so.
On almost all of our site templates, it works just fine. In a few scattered, unpredictable situations, there is a crippling, browser-crashing experience that may turn away some users.
We're not able to see a relationship between the crashing templates at this time, and while there are many ways to troubleshoot, the one that's confuddling us is related to event listeners.
The sites crash when any anchor on these templates is clicked. There isn't any inline JS, and while we firebug'ed our way through the attributes of the HTML, we couldn't find a discernable loop or issue that would cause this. (while we troubleshoot, you can experience this for yourself here [warning! clicking any link in the page will cause your browser to crash!])
How do you determine if an object has a listener or not? How do you determine what will fire when event is triggered?
FYI, I'd love to set breakpoints, but
between Omnitures miserably obfuscated code and repeated browser
crashes, I'd like to research more
thoroughly how I can approach this.
I did an "inspect element" on a link in that page with firebug, and in the DOM tab it says there is an onclick function (anonymous), and also some other function called "s_onclick_0".
I coaxed firebug placing a watch like
alert(document.links[0].onclick)
to alert me the onclick function that omniture (i guess) attaches to links:
function anonymous(e) {
var s = s_c_il[0], b = s.eh(this, "onclick");
s.lnk = s.co(this);
s.t();
s.lnk = 0;
if (b) {
return this[b](e);
}
return true;
}
Maybe in the same way you can see what it is really running after all that obfuscation.
DOM doesn't provide any means to introspecting through the events listeners' collections associated with a node.
The only situation where listener can be identified is when it was added through setting a property or an attribute on the element - check on onxxx property or attribute.
There have been a talk recently on WebAPI group at W3 on whether to add this functionality. Specialists seem to be against that. I share their arguments.
A set of recommendations to the implementers of on-page analytics:
Use document-level event capturing only, this is in almost every case (besides change/submit events) sufficient
Do not execute computation-intensive code (as well as any IO operations) in the handlers, rather postpone execution with a timeout
If this two simple rules are taken into account, I bet your browser will survive
I have some experience with Omniture and looking at your s_code.js, you have several things going on in the "Link Tracking" area, for example:
/* Link Tracking Config */
s.trackDownloadLinks=true
s.trackExternalLinks=true
s.trackInlineStats=true
s.linkDownloadFileTypes="exe,zip,wav,mp3,mov,mpg,avi,wmv,pdf,doc,docx,xls,xlsx,ppt,pptx"
s.linkInternalFilters="javascript:,gatehousemedia.com"
s.linkLeaveQueryString=false
s.linkTrackVars="None"
s.linkTrackEvents="None"
I would consult with the people at Omniture and verify that your link tracking configuration is set up correctly.
Specifically, this template and the links inside seem to belong to morningsun.net and yet morningsun.net is not in the s.linkInternalFilters setting. If you are using the same s_code.js file for multiple domains, you can use javascript to set the configuration values for things like this (basing on the document.location.hostname for instance).
I don't personally have experience with the link tracking configuration or I would give you more detail on how to configure it :)
While traveling home I came to a solution that allows for introspection of event handlers on element added with AddEventListener. Run code before the inclusion of your analytics code. The code was not verified if works, but the idea, I guess is clear. It won't work in IE, however you can apply similar technique (of rewriting the API member) there as well.
(function(){
var fAddEventListener = HTMLElement.prototype.addEventListener;
HTMLElement.prototype.addEventListener = function() {
if (!this._listeners)
this._listeners = [];
this._listeners.push(arguments);
fAddEventListener.apply(this, arguments);
}
})();