I am probably one of these developers that falls into this trap over and over again because I never use IE personally and actually hate it with a passion.
I do test in IE for the majority of things, especially layout as this is what everyone will notice first, but there are some things which I forget to test because I asume that as they are working in Chrome/Firefox/Opera/Safari/Mobile Browsers that they would work in IE.
This happened to me recently while developing a cross site scripting widget which would allow for 3rd parties to add reference a javascript file from our server, then it would do some fancy stuff and read a page on our server.
The script would use jQuery's Ajax Get method to read the contents from an ASP.NET web page (.aspx), so not a web service or WCF service, just a web page that would output the response in HTML.
I had tested everything locally, and then tested in the live environment. Everything was working as far as I was aware, until I was notifed out the IE issue. To me the problem was not with my code, but with versions of the jQuery library or other IE bugs on this third party website. Eventually I identified the problem.
$.get(url, function (data) { }); // cross site
Doesn't work in IE. Eventually after a lot of searching and going off on wild goose chases I found the solution. XDomainRequest()
// check for IE browser if ($.browser.msie && window.XDomainRequest) { // Use Microsoft XDR var xdr = new XDomainRequest(); xdr.contentType = "text/plain"; xdr.open("get", url); xdr.onload = function () { // handle response via xdr.responseText }; xdr.send(); } else { // good browser :P $.get(url, function (data) { }); // cross site }
This is a simple solution which checks if the client browser is IE and then uses XDomainRequest(). On the ASP.NET page side I had to add
Response.AppendHeader("Access-Control-Allow-Origin", "*")
In order to allow the request.
