DOMParser's parseFromString function and IE 9

When Internet Explorer 9 is running in Standards mode the DOMParser object is now available.

The DOMParser object allows one to convert a string of XML into a document object by calling the DOMParser's parseFromString function.

This article will focus only on the DOMParser object and will not do the standard feature detection tests that should be done for cross-browser compatibility (this code will break if IE 9 is not running in Standards mode or if you are using a previous version of IE).

If you are interested in seeing how to do proper feature detection tests for the DOMParser object, the following article has an example function called ConvertStringToXMLObject:
http://cggallant.blogspot.com/2011/03/xmlhttprequest-calls-when-in-ie-9.html

Something to be aware of with the DOMParser's parseFromString function is that the resulting XML document may have attributes that are rearranged compared to the attributes of the XML string that was passed in.

For example, if we have the following string of XML one would expect that the resulting XML document object would be an exact replica of the original XML string:

var sXML = "<TEST ID=\"124\" TITLE=\"TitleValue\" DATE=\"2011-02-24T00:00:00\" STATUS=\"Processing\" EMPNAME=\"Smith, Sam\" STATUSCODE=\"P\" ROWNUM=\"1\" />";

What has been discovered, however, is that if you pass the above XML string into the DOMParser's parseFromString function, the attributes in this case are completely reversed:

var dpParser = new DOMParser();
var xdDoc = dpParser.parseFromString(sXML, "text/xml");

// Grab the root 'Test' node from the document object and then
// loop through the attributes
var xnTest = xdDoc.getElementsByTagName("TEST")[0];
var xaAttrib = null;
var iAttribCount = xnTest.attributes.length;
for (var iIndex = 0; iIndex < iAttribCount; iIndex++){

// Grab the current attribute and display its name
xaAttrib = xnTest.attributes[iIndex];
alert(xaAttrib.nodeName);

}

The result shows that the XML attributes passed in are now in reverse order:

<TEST ROWNUM="1" STATUSCODE="P" EMPNAME="Smith, Sam" STATUS="Processing" DATE="2011-02-24T00:00:00" TITLE="TitleValue" ID="124" />

A bug was filed with Microsoft on this issue but, unfortunately, Microsoft has indicated that the parseFromString behavior is by design.

The best advice that can be given for this situation is to not iterate over the attributes using indexes and instead to grab the attribute values by name as in the following example:

var xnTest = xdDoc.getElementsByTagName("TEST")[0];
var sID = xnTest.getAttribute("ID");

XMLHttpRequest calls when in IE 9 Standards mode

With Internet Explorer 10 (IE 10), the issue described in this article has been fixed if the browser is using IE 10 Standards Mode.

With all versions of Internet Explorer, even when IE becomes more standards compliant, there are usually workarounds that are still needed.

Even though IE 9 is the most standards compliant Microsoft browser to date, there are still several things that have been discovered that we need to be aware of.

Feature detection tests should always test for W3C features first and fall back to IE specific features if the W3C feature is unavailable. For example, the following would be the feature detection code to use to create an XML object from a string of XML:

function ConvertStringToXMLObject(sXML) {

// Test for W3C feature
if (DOMParser) {

var dpDOMParser = new DOMParser();
return dpDOMParser.parseFromString(sXML, "text/xml");

} else { // IE 8 and previous or IE 9 when *not* in Standards mode...

var xdDoc = new ActiveXObject("Microsoft.XMLDOM");
xdDoc.loadXML(sXML);
return xdDoc;

}

}

When Standards mode is on, IE 9 now supports the DOMParser object. The issue with this, however, is that the XMLHttpRequest object still returns an MSXML ActiveX object from the reponseXML property no matter which document compatibility mode IE 9 is using.

The MSXML ActiveX XML object is not compatible with the DOMParser XML object and will result in a 'Type mismatch' error if you try to append the one XML object to the other.

The workaround for this issue is to pass the responseText property, from your XMLHttpRequest object, to your client-side XML object creation function so that you get an XML object of the proper type as in the following example:

function MakeServerSideCall(sURL, sPostData) {

var xhrRequest = GetXMLHttpRequestObject();
xhrRequest.open("POST", sURL, false);
xhrRequest.send(sPostData);

return ConvertStringToXMLObject(xhrRequest.responseText);

}


function GetXMLHttpRequestObject(){

var xhrRequest = null;

if (window.XMLHttpRequest) { xhrRequest = new XMLHttpRequest(); }
else if (window.ActiveXObject) { xhrRequest = new ActiveXObject("Microsoft.XMLHTTP"); }

return xhrRequest;

}

The following is a Microsoft article which talks about the DOMParser object, XMLSerializer object, as well as this workaround for the XMLHttpRequest object:
http://blogs.msdn.com/b/ie/archive/2010/10/15/domparser-and-xmlserializer-in-ie9-beta.aspx

Document Compatibility Modes in Internet Explorer 9

Document compatibility determines how Internet Explorer renders your web page and how the JavaScript will work.

IE 8 and later will first determine how to render a page based on the X-UA-Compatible header which I'll discuss in a moment.

If the X-UA-Compatible header is not present, IE then looks for the DocType directive to determine how to render the page.

If the DocType directive is missing or does not specify a standards-based document type then the web page is rendered in IE 5 mode (Quirks mode of IE 7).

The recommended DocType in IE 9 is the HTML 5 DocType which will cause IE 9 to use Standards mode:

<!DOCTYPE html>

In my reading on the DocType directive I ran across an MSDN article that indicated that IE will also switch on Standards mode if the DocType includes a URI.

In my testing, including the URI in a DocType does appear to cause IE 9 to use Standards mode. Being able to use Standards mode even if the HTML is not HTML 5 allows us to make use of the latest JavaScript functionality in IE 9.

The following is an example of an HTML 4 DocType that causes IE 9 to use Standards mode:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

If a web site does not work correctly in Standards mode it's recommended that the site be updated to use the most up-to-date features.

There are times, however, when you may want to force a web site to display using a specific document compatibility mode.

An example situation where you may want to force a web site to display using a specific document compatibility mode could be that perhaps you have a product that is live and you don't have time to upgrade it before people start using the latest IE browser.

Even when a web site's JavaScript has been written to do feature detection for W3C compliant features and only fall back to IE specific features if the W3C feature is not available, IE 9 still throws some curve balls.

One curve ball that IE 9 throws is that, even in Standards mode, an MSXML ActiveX object is returned rather than a DOMParser object when making an XMLHttpRequest. The resulting XML document is incompatible with any XML documents that are created using the DOMParser.

The workaround is to return XML as text and turn the responseText value into an XML document object by using the DOMParser (the following MSDN article explains this process a bit more: http://blogs.msdn.com/b/ie/archive/2010/10/15/domparser-and-xmlserializer-in-ie9-beta.aspx).

There are several options available to cause IE to use a document compatibility mode other than IE 9 Standards mode.

Compatibility View button

The first option for changing the document compatibility mode is that an end user can click the Compatibility View button which will cause IE 9 to switch to IE 7 Standards mode.

(click to view the image full size)

The web site is listed in a Compatibility View list until the user removes the web site from the list by either clicking the Compatibility View button again or uses the Compatibility View Settings dialog.

You can find the Compatibility View Settings dialog by pressing Alt on your keyboard to show the menu bar and then select the Tools, Compatibility View settings menu item.

The Compatibility View Settings dialog allows the user to cause all Intranet sites, as well as all web sites, to use the Compatibility View setting by means of two checkboxes at the bottom of the dialog.

(click to view the image full size)

If the Compatibility View Settings checkboxes are checked, and you are viewing one of the respective types of web sites, you will not see the Compatibility View button in the address bar.

IE 9 Developer Tools

A temporary way to change the document compatibility mode of the browser is through the IE 9 Developer Tools.

You can display the Developer Tools by pressing F12.

Changing the selection of the Browser Mode or Document Mode drop-downs causes the web page to refresh and render according to the selected modes:

(click to view the image full size)

This technique is helpful if a developer wants to test how a web page renders in IE 9, IE 8, and IE 7 without having to switch to another computer since you can't install Internet Explorer versions side-by-side.

This saves a lot of time when trying to debug why something suddenly started breaking in IE 9 that didn't break in IE 8 for example.

In my testing so far, these settings appear to cause IE 9 to behave as expected but it's not a replacement to testing with the actual IE 7 and IE 8 browsers.

X-UA-Compatible meta tag

As a web developer you may decide that a page needs to be rendered using a certain document compatibility mode but only certain pages have this requirement.

You can include an X-UA-Compatible meta tag on one or more pages within the web site to tell IE how to render the page.

The meta tag needs to be the first tag in the Head section of a page following only the Title tag as in the following example:

<head>

<title>The Page Title</title>
<meta http-equiv="X-UA-Compatible" content="IE=8" />

</head>

Available values for the X-UA-Compatible setting are:

• 5 (renders as if IE 7 in Quirks mode which is very similar to how content was rendered in IE 5)
• 7, 8, and 9 (these ignore the DocType if present and display as if in Standards mode of the browser specified)
• EmulateIE7, EmulateIE8, EmulateIE9 (these take the DocType into consideration and displays using Standards mode or Quirks mode of the browser specified)
• Edge (this tells the browser to use the highest mode available and is not recommended in production environments)

The X-UA-Compatible value as an HTTP Response Header

For a small web site simply dropping in the X-UA-Compatible meta tag is not a large task but if you have a web site with hundreds of pages, adding and maintaining the meta tags would be quite the task.

The better approach if you need to include the X-UA-Compatible value for an entire web site is to include the value as an HTTP Response Header

In conclusion

It is recommended that you always try to make sure your web pages work correctly in the latest versions of IE.

There are times, however, when you may need to temporarily tell Internet Explorer to display a page or website in a document mode used by a previous version of the browser which makes being able to specify the document compatibility modes a handy feature to have.

The following is a link to an MSDN article on Defining Document Compatibility if you would like to read more on the subject:http://msdn.microsoft.com/en-us/library/cc288325%28v=vs.85%29.aspx

Viewing JavaScript Errors in Internet Explorer 9 and 10

With Internet Explorer 10 (IE 10), it is not currently possible to view JavaScript errors when using the metro version of the browser.

The contents of this article still apply to IE 10 but only when using the desktop version.

To switch from the metro version of IE 10 to the desktop version, click on the Settings button in the browser and choose the 'View on the desktop' menu item.

JavaScript error reporting is a bit different in Internet Explorer 9 and 10 compared to previous Internet Explorer browsers since, by default, the Status bar is not visible and depending on your settings this might be the only place that would indicate if there was an error on the page.

You can turn on the Status bar either through the menu system by pressing Alt on your keyboard to show the menu bar and then navigating to the View, Toolbars, Status bar menu item.

Another approach to showing the Status bar is to right-click on title/tab area and choose the Status bar option from the context menu.

JavaScript Errors on the Status Bar

Getting errors to show via the status bar seems to be hit and miss because sometimes it works for me and sometimes it doesn't. It is my guess that Microsoft intends to remove the status bar error log functionality altogether and that it is simply an oversight (bug) that lets us view the error log in the first place.

In my testing if you start the browser normally the Status bar behavior I'm about to describe will not work.

If you launch IE from a pinned site, however, this Status bar behavior usually works.


To pin a site, drag the icon that is on the address bar to the Windows taskbar.

(click to view the image full size)

In your Advanced settings, if you have the 'Display a notification about every script error' option turned off then even if you have the status bar visible, you will not know there was an error.

The only hint of a JavaScript error would be if the page didn't respond properly (something didn't load for example).

The following is a screen shot of a website launched from a pinned site that has thrown an error (the status bar doesn't indicate that there was an error):

(click to view the image full size)

If you double-click anywhere on the status bar, if there was a JavaScript error on the page, the error log will pop-up.

(click to view the image full size)

If you have the 'Display a notification about every script error' option turned on then you will get a bit more feedback when a JavaScript error happens on the page.

Now, when a JavaScript error happens, the error log pops up showing us the error and, when we dismiss it, the status bar tells us there was an error on the page.

(click to view the image full size)

Whether or not the status bar was visible at the time of the JavaScript error doesn't matter. If you show the status bar and then double-click on it, you will see the error log.

Viewing JavaScript Errors from the Developer Tools

Since the status bar is no longer reliable for viewing if there was a JavaScript error on the page there is another approach available for viewing JavaScript errors.

Internet Explorer has a set of tools built in called Developer Tools and they can be displayed by pressing F12. The following is a screen shot of the Developer Tools window:

(click to view the image full size)

In the Developer Tools is a Console tab that shows you a log of all JavaScript errors on the page since the Developer Tools were opened.

The trick with the Console tab of the Developer Tools is that the error log only starts logging errors once the Developer Tools window is opened.

(click to view the image full size)

You will need to repeat the action that triggered the error in the first place to see the error in the Console tab.

The following is a screen shot of the Console tab with a JavaScript error logged:

(click to view the image full size)

In Conclusion

If you think there was a JavaScript error on the page, and the web page was launched from a pinned site, then double-clicking the Status bar usually displays the JavaScript error log if there were errors.

The Console tab of the Developer Tools (F12) will also give you a list of all JavaScript errors that happened on the page regardless of if the web page was launched from a pinned site or not.

The only issue with the Console tab's error logging is that it only starts logging errors once the Developer Tools window has been opened forcing one to repeat the steps to try and trigger the error again.