I'm using a KML plugin for leaflet that works great in Google Chrome. In IE, however, It throws an error at the following code.
parser=new DOMParser();
console.log(url) // outputs: "path/to/kmlfile.kml" in Chrome debugger
url=parser.parseFromString(url,"text/xml"); //This line throws a parser error in IE 11, but is fine in Chrome
It seems to me that there is a mistake in this code - the author should pass an actual XML string, not just a url to an XML document to the parser.parseFromString() function. It makes sense that the parser would have an error, as a path to a file is not a valid XML file (Note: kml files are just XML). However, this does not cause any errors to be thrown in the Chrome Debugger tools, which is really strange.
It seems to me that this should fail in both instances. Trusty MDN docs on DOMParser have no mention of putting a URL as a parameter in parseFromString(). So my question is why is this working in Chrome, but throwing an error in IE, and then what can I do to fix it?
Note this question is different from the following url because this isn't a general error - this is about something that works in Chrome but fails in IE: Internet Explorer 11 (IE 11) Throws Syntax Error using parseFromString in DOMParser
When the XML is malformed non-Microsoft browsers (Firefox, Chrome, etc) it will create the XML document with the error message as it's content. Click here (<-- click there).
When the XML is malformed in Microsoft browsers, IE and Edge, it throws an error, writes an error to the console and your script stops. Note I'm on a Mac so I've tested this remotely but have not had a chance to test it personally. You can put that code in a try catch block for IE but what I mean is I don't know if that will stop it from writing a message to the console.
Here's the code pen with intentionally malformed XML and the error message is written in the output. There is no error in the codepen or output. I'm intentionally writing the error code from the parser to the output window. Open the console to see what's going on.
FWIW IE is the correct behavior IMHO. Not throwing errors was the Internet way to do things until relatively recently. The problem with not throwing errors is you don't know what you did wrong or where. Write once, debug everything.
Also, until more recent versions, IE used ActiveX to parse XML documents.
From W3C XML validation script:
function validateXML(text) {
var message;
var parser;
var xmlDoc;
// code for Edge, IE, Mozilla, Firefox, Opera, etc.
if (document.implementation.createDocument || window.DOMParser) {
parser = new DOMParser();
try {
xmlDoc = parser.parseFromString(text, "text/xml");
}
catch (error) {
}
if (xmlDoc.getElementsByTagName("parsererror").length > 0) {
return xmlDoc.getElementsByTagName("parsererror")[0];
}
else {
return "No errors found";
}
}
// code for older versions of IE
else if (window.ActiveXObject) {
xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
xmlDoc.async = "false";
try {
xmlDoc.loadXML(text);
}
catch (error) {
}
if (xmlDoc.parseError.errorCode != 0) {
message = "Error Code: " + xmlDoc.parseError.errorCode + "\\n";
message = message + "Error Reason: " + xmlDoc.parseError.reason;
message = message + "Error Line: " + xmlDoc.parseError.line;
return message;
}
else {
return "No errors found";
}
}
else {
return "Not supported";
}
}
Related question.
Related
I have a very simple function that downloads chunks of a file using an xhr request that looks like so:
var blobXHR = new XMLHttpRequest();
//api.media.chunkURL() returns the correct URL for each chunk
blobXHR.open("GET", api.media.chunkURL({
fileId: fileID,
chunkId: chunkNumber
}));
blobXHR.responseType = "arraybuffer";
blobXHR.onerror = function (e) {
console.log("Error: ", e);
};
var arrayBuffer;
blobXHR.onload = function (e) {
arrayBuffer = blobXHR.response;
};
blobXHR.send();
Now this download function works without any hitches at all using Chrome, Firefox, and just about every Android browser. Unfortunately, when using anything Safari or iOS based I get a very vague error in blobXHR.onerror(). When I output this error to the console I get this response under "e.currentTarget.responseText":
Error: InvalidStateError: DOM Exception 11
I've looked up many questions similar to this and nothing has seemed to work. Any reason why I would be experiencing this with only Safari/iOS browsers?
Edit: This is what I get when I console.log(blobXHR) within onerror():
This is likely a CORS issue. Make sure your server is properly configured to allow this:
http://enable-cors.org/server.html
Also be mindful that Safari won't allow localhost for CORS.
The following javascript function works fine for IE, Safari and Firefox. But it fails in Chrome(33.0.) and Opera (16.0.1196). Blank HTML page is displayed on loading.
function readTestXMLFile() {
if (window.ActiveXObject) {
var xmlDoc = new ActiveXObject('Microsoft.XMLDOM');
xmlDoc.async = 'false';
xmlDoc.load('test.xml');
}
else {
var requ = new XMLHttpRequest();
alert("a");
requ.open("GET", "test.xml", false);
alert("b");
requ.send(null); //This line is not working in chrome and opera
alert("c");
var xmlDoc = requ.responseXML;
alert(xmlDoc);
alert("d");
}
return xmlDoc;
}
Only 'a' and 'b' gets printed. It does not continue after that. Same result is observed if I use requ.send() or requ.send("") instead of requ.send(null).
If I remove the statement requ.send(null), then 'null' value is printed for xmlDoc. Still blank HTML loads.
Please let me know what is the right way to get this work on Chrome and Opera.
Thanks
SRB.
Your error message suggest that you are trying to access a local file which is treated as "Cross origin request" if you try and run local server it should work.
Take a look at this previously asked question with the same problem:
Cross origin requests are only supported for HTTP but it's not cross-domain
Then you would access http://localhost/.../test.xml instead of c:/localhost/.../test.xml
You can also set a flag for Chrome to allow local files to request local files: -allow-file-access-from-files
the call to the XMLHttpRequest.send method is Asynchronous so you need to modify the call a little bit. The modified code below will print the response content when the response is returned successfully:
requ.addEventListener("load", function(e) {
alert(req.responseText);
}, false)
requ.send(null);
Update:
I didn't notice that you made the send request call synchronous.
Edit
You need to launch chrome with this parameter to be able to access local files
--allow-file-access-from-files
ex: c:\Browser\chrome.exe --allow-file-access-from-files
I think that the problem is that you're passing null to the send() method. You are making a GET request, so you should call send without parameters. I think chrome throws an exception because of that. Just remove the null
When I run the following code in webkit browsers, I get an error outputted to the console despite having my code wrapped in a try/catch block.
var externallyFramed = false;
try {
externallyFramed = top.location.host != location.host;
} catch (e) {
externallyFramed = true;
}
The error I get is the following:
Unsafe JavaScript attempt to access frame with URL...
Is there anything I can do differently to prevent the error from showing up?
How do I detect if ActiveX is enabled in the browser of client?
I tried following code, but it's not working in Firefox.
window.ActiveXObject not working in Firefox
any ideas?
check the example here: http://jsfiddle.net/qXSvQ/2/
I get false when I run this example.
ActiveX objects do not exist in anything but Internet Explorer. If you're trying to use them for XMLHTTPRequests, use the XMLHTTPRequest() object instead, using feature detection.
if ("ActiveXObject" in window) { /* Do ActiveX Stuff */ }
else { /* ActiveX doesnt exist, use something else */ }
What isn't working? Is that throwing an error in FF? How about
var hasAX = "ActiveXObject" in window;
Below code should work, It is working on IE6 & FF 3.6.12 atleast.
if(typeof(window.ActiveXObject)=="undefined"){
alert("ActiveX Object not supported");
}else {
alert("ActiveX Object supported");
}
It seems Firefox simply skips scripts containing ActiveX objects:
<script><!--
var activeXsupport = "ActiveX not supported";
// --></script>
<script><!--
var dummy = new ActiveXObject ('WScript.Shell');
activeXsupport = "ActiveX supported";
// --></script>
<script><!--
alert (activeXsupport);
// --></script>
So this gives me "supported" on IE11 and "not supported" on Firefox.
[Edit:] Since it also throws an error message on Firefox if the console is opened with [F12], I suggest this improvement:
<script><!--
var dummy = ''; var hasActiveX = false;
try {dummy = new ActiveXObject ('WScript.Shell'); hasActiveX = true;}
catch (err) {dummy = ''; hasActiveX = false;}
alert ('hasActiveX = ' + hasActiveX);
// --></script>
Edge Chromium supports ActiveX if it is made the default browser in settings and reloading in Internet Explorer Mode via "More Tools" is enabled:
edge://settings/defaultBrowser
Gerolf
I create an error message its working with IE and Mozila.
Not woking with Safari, Chrome and Opera.
But I need to use it. Please give me right way for doing it.
<script language="javascript" type="text/javascript">
window.onerror = function(msg, url, line)
{
document.write("Message\t = "+msg + "<br/>Location\t = " + url + "<br/>Line No.\t = " + line + "<br/>Error No.\t = " + this.err.number);
}
this.err = Error(12,"My Own Error");
throw this.err;
</script>
==========================================
Internet Explorer:
My Error
Message = My Own Error
Location = http://localhost/practice/JavaScript/window.errors.php
Line No. = 8
Error No. = 12
================================================
Mozilla FireFox:
My Error
Message = Script error.
Location = My Own Error
Line No. = 0
Error No. = undefined
=====================================================
Safari, Chrome, Opera:
My Error
look the code Mozilla give wrong information. what I do?
Opera doesn't support window.onerror at all. Chrome supports it, but not on errors that you throw yourself. This is also true of Internet Explorer when using Error objects other than Error(), e.g. TypeError(). Chrome also doesn't provide the line and file arguments.
You should correctly catch any exceptions you're going to throw with a try...catch statement, instead of relying on window.onerror.