So I followed some tutorials for uploading files asynchronously. The project runs fine for Mozilla Firefox and Chrome, but when i run it in Internet Explorer 9 it gives an error:
0x800a138f - Microsoft JScript runtime error: Unable to get value of the property 'length': object is null or undefined
here is where it shows the error:
<script type="text/javascript">
$(document).ready(function () {
$("#btnUpload").click(OnUpload);
});
function OnUpload(evt) {
var files = $("#fileUpload").get(0).files;
if (files.length > 0) { <---//Error
...
I have already tried some fixes e.g adding this to the head tag
<head>
<meta http-equiv="X-UA-Compatible" content="IE=9" >
This doesn't work for me.
So help would be greatly appreciated.
You haven't specified what jQuery plugin you're using for the file upload, but my guess is that it's one which is using a browser feature (File API) that isn't available in older browsers like IE9.
There are ways of uploading files using old browsers; if you want to support IE9, you'll have to use one of the older techniques.
You might want to look at some of the libraries listed here -- this is a list of "Polyfill" libraries which claim to allow some degree of compatibility for this new feature in older browsers. I can't guarantee that any of them will work nicely with your existing jQuery plugin, but they should at least give you a starting point for getting the feature working.
Related
I am having some troubles on listing the plugins from IE plugins using Javascript like Panopticlick does.
I am using the plugin.name but it does not run on IE
Any suggestions or used code examples? Thank you
navigator.plugins will work for IE 11 but not for earlier IEs. More on IE and plugins can be read here. For earlier IEs, you will need to check for each plugin manually by trying:
try {
new ActiveXObject('aPluginName');
return true;
} catch(e) {
return false;
}
Main problem is, that plugins in IE are ActiveX based, which means each has its own API and there is no way you can check this in a general "catch-them-all" way. I found this link quite helpful.
At one point in our system we use javascript to read in a chunk of XML and then query that XML document using xPath.
Prior to IE 11, IE supported using xmldoc.selectSingleNode(“//xpath/string”) and the non IE browsers supported using a xmldoc.evaluate(“//xpath/string”). These both returned a similar object that we could then carry on interpreting to extract the data required.
In IE11 neither of these methods seem to be available.
It seems that IE11 has some support for XML documents in that when I read in the xml using the DOMParser object using the parseFromString method, it returns an object that the IE11 debugger calls an XMLDocument.
Thanks to #Martin Honnen for pointing out that some ActivXObjects are still supported in IE11!
var doc;
try {
doc = new ActiveXObject('Microsoft.XMLDOM');
doc.loadXML(stringVarWithXml);
var node = doc.selectSingleNode('//foo');
} catch (e) { // deal with case that ActiveXObject is not supported }
I've used "Microsoft.XMLDOM" as it is sugested here that it is a more generic call to what ever xml parser is present on the system, where as it sounds like "Msxml2.DOMDocument.6.0" will fail if that exact version is not present. (We do have to support all IE vers back to 6.0 at my place!)
This just works as it always has done. The only problem I had was that the old switch I used to detect IE vs other browsers was if (typeof ActiveXObject !== "undefined") failed as I guess they are trying to discourage it's use!
Thanks all for your help.
To expand on pixelmatt's answer, some results of my tests (Win 7 64bit with IE11) I did in order to get DOMParser to work as it did in IE9 and IE10 (in IE11 it now returns an XMLDocument object which appears to not support xpath queries?).
Turns out I could make it behave like in IE10 with the following meta tag:
<meta http-equiv="X-UA-Compatible" content="IE=10" />
Results without and with above meta:
And here are the XMLDocument's memebers (for reference):
In one of my web pages, I am using the following line of JavaScript:
return !!(a.compareDocumentPosition(b) & 16);
However, only in IE9, I am getting the following error:
Object doesn't support property or method 'compareDocumentPosition'
Other browsers work fine. Does anyone know of an available fix or workaround for this?
Internet Explorer supports compareDocumentPosition only in IE9 mode. Make sure you have at the beginning of your markup and document.documentMode returns 9
I have NPAPI plugin and I want to detect its version before I embed it into web page. If version is not the latest one I want to show some message that asks users to update the plugin.
Now it's implemented in the following way
if (navigator.mimeTypes && navigator.mimeTypes["application/myplugin"]) {
{
// some code here
if(navigator.plugins["myplugin"] && navigator.plugins["myplugin"].version >= latest_version) {
// we have the latest version (embed the plugin into web page)
document.write ("<object id='plugin'><embed ....></object>");
} else {
document.write ("Show message here");
}
// some code
}
The problem is that navigator.plugins["myplugin"].version works fine in Firefox but not in Chrome. Chrome doesn't expose version property. I can add my own property in NPAPI code, but I don't see the way I can use it before embedding the plugin into page.
Is there any workaround?
Thanks in advance, Andrew
I see a lot of plugins have version information in either the name or the description. You should be able to access that information before the embed.
I actually put the version number in the filename, rather than even the name or description. The reason for this is that if there are multiple plugins with the same name, description, and mimetypes Firefox will generally use the latest version. Older versions of firefox have been inconsistent in how they handle this, so I even usually put the np???_version.dll file in a version-specific subdirectory.
It is a little bit of a pain, but it works consistently the same way in every NPAPI browser.
You can create a JSAPI property of your plugin containing the version. This property returns the plugin's version when called from javascript. So when you try to insert/embed the plugin in the page, you can check through javascript to make the appropriate calls.
Whilst trying to get our app working in Firefox (I'm a big proponent of X-Browser support but our lead dev is resisting me saying IE is good enough). So I'm doing a little side project to see how much work it is to convert.
I've hit a problem straight away.
The main.aspx page binds to a webservice using the IE only method of adding behaviour through a htc file, which is auto-generated by VS I beleive.
Firefox doesn't support this but there is an xml bindings file which can be used to enable htc support (see here: http://dean.edwards.name/moz-behaviors/overview/). The examples work in FF3 but when I use my webservice.htc as I normally would e.g.:
//Main.aspx
/*SNIP*/
<style type="text/css" media="all">
#webservice
{
behavior:url(webservice.htc);
-moz-binding:url(bindings.xml#webservice.htc);
}
</style>
</head>
<body>
<div id="webservice"></div> <!-- we use this div to load the webservice stuff -->
/*SNIP*/
//Main.js
webservice.useService(url + asmpath + "/WebServiceWrapper.asmx?WSDL","WebServiceWrapper");
I get webservice is not defined (works fine in IE), I obviously tried
var webservice = document.getElementById("webservice")
and
$("#webservice").useService(url + asmpath + "/WebServiceWrapper.asmx?WSDL","WebServiceWrapper");
as well which just gives me "useService is not defined" in Firebug. Which leads me to beleive that the binding is not working. However I can see that webservice.htc is being loaded by Firefox in the Firebug console window.
Anyone got any experience of this?
Am I going to have to rewrite how the webservice is called?
Cheers,
Rob
I don't think that you are on the right way for achieving real cross-browser compatibility. Adding support for IE-specific features for Firefox is definitely not the way to go. What about Opera, Safari, Chrome...? If the app you're working on is used strictly on the intranet then supporting Firefox may be enough however...
IMHO, the code should be refactored, but in an other way. If you are working with ASP.NET 2.0 (in this case you'd need ASP.NET Ajax) or newer, you can create proxy between Ajax and SOAP web services. In that case you would need to rewrite all your behaviors as a JavaScript code which may not be a small feat.
On a side note: AFAIK VS.NET does not generate behaviors.
Sorry if this is not too helpful :(
Your jQuery snippet has an error: since useService is a method defined on the node itself, not the jQuery object, you'd have to do:
$("#webservice")[0].useService(url + asmpath +
"/WebServiceWrapper.asmx?WSDL","WebServiceWrapper");