IE9 ActiveX filtering, XML Islands and Making the Workarounds to Get Things Work

Introduction

If your website suddenly stopped working in IE9 because you can't parse XML and xml = new ActiveXObject( "Microsoft.XMLDOM" ) evaluates to null, the land is burning under your legs and you need some solution to parse XML without ActiveX:

The magic solution is here.

But you are still welcome to read this tip and hopefully you will learn a lot of interesting things!!!

Internet Explorer 9 introduced a new feature called "ActiveX filtering" which can be enabled by user or by administrator as a part of security policy in order to reduce the risk of running malicious code which ActiveX can contain. Do your web applications rely on parsing XML, even with jQuery? There is a good chance it will be completely broken in IE9 when ActiveX filtering is enabled. Are your web applications used inside enterprise company , or may be bank - be sure the policy is enabled. :)

Background

Below you can find my sad story about my battle with IE9 and ActiveX filtering.

The good news is that battle was successful at this time, because an elegant solution was found and good lessons were learned.

One day, I was awakened by support call when the problem was in some of the web applications used for data visualization. The app was completely broken, saying it can't parse XML string into the object, but it happened only for IE9 users..

I will leave all the funny details of 3 days investigations and how actually I understood that problem is with IE9 ActiveX filtering, making the result of this code xml =new ActiveXObject( "Microsoft.XMLDOM" ) evaluate to null.

The application uses jQuery.xml function to parse XML so after digging inside the code, we can see the following code snippet (shortened for your convenience):

if ( window.DOMParser ) { // Standard
                var tmp = new DOMParser();
                xml = tmp.parseFromString( data , "text/xml" );
} 
else { // IE
    xml = new ActiveXObject( "Microsoft.XMLDOM" );
}      

But stop a second, why we get to: xml = new ActiveXObject( "Microsoft.XMLDOM" ) section in spite of the fact that IE9 has support for DOMParser like all other modern browsers ..?

The answer is simple: IE9 decided that it wants to run the web site in IE8 browser and document mode because the application forces it to do so by using <meta http-equiv="X-UA-Compatible" content="IE=8"> meta tag.

*** It is worth saying that I saw many other web sites which IE9 decided to run in IE8/7/Quirks modes according to some undocumented rules only Microsoft is aware about, even without specifying the above meta tag.

I was out of luck changing it back to IE9 mode: GUI of application in IE9 mode was completely broken.

In my situation, the fix needed to be done quickly with minimal code regression, I started to think about an alternative way of parsing XML (without using ActiveX) instead of trying to fix all of the IE9 incompatibilities in GUI. When actually understanding that the right solution will be to make everything work properly in IE9 mode...

Solution

And a surprisingly elegant solution exists in Internet Explorer: XML Data Islands.

The technology is old as Internet Explorer, but is very simple to use and gives us the ability to embed the pieces of XML data inside the HTML document and ability and get the XmlDocument in JavaScript.

So here are the magic lines which will give you XmlDocument from string:

function parseWitoutActiveX(str){
var doc= null;
var xmlIsland = document.createElement('xml');
if(xmlIsland){
xmlIsland.setAttribute('id','xmlActiveXGetRid');
xmlIsland.innerHTML = str;
document.body.appendChild(xmlIsland);
var doc  = xmlIsland.XMLDocument;
document.body.removeChild(xmlIsland);
return  doc;
}

Lessons Learned

All the tricks you do will be returned to you :) and you will need much more time to resolve it.

The whole incident can be avoided if from the beginning, the effort to make things work in IE9 was taken.

Bad decisions in the past are ruling you to make bad decisions in the future: the right decision also for me was to make the web site work properly in IE9, but we all know this is not possible in the majority of situations in a hot fix flow ... , when customers are disappointed and are expecting an immediate solution.

In spite of all that I said above, I don't think we need to blame only the developer who inserted the meta tag inside here in order to make things work.

Developers always have pressure to deliver the feature, which is reasonable in most variety of cases from the business point of view but business people who are responsible for running organizations need always to know that this is always a big hidden trade-off in decisions to bootstrap the things with the help of patches.

Credits

• Dean Edwards for his nice article