Click here to Skip to main content
15,798,066 members
Articles / Programming Languages / Javascript

IE XML5633 Error when using jQuery.parseXML()

Rate me:
Please Sign up or sign in to vote.
5.00/5 (1 vote)
11 Jun 2014CPOL3 min read 16K   1   1
The HTML returned in the AJAX request was actually invalid XML. For XML5633, IE shows a console error even if it's inside a try/catch block.

I saw something very interesting today while debugging an issue that a QA reported. They learn as part of their training to always keep Dev Tool open, and create a bug when a console error comes up. The bug I was looking at was created when a QA saw the following:

XML5633: End-tag name does not match the corresponding start-tag name. Line: 1, Column 10

I ran a Fiddler trace, and noticed an AJAX request was throwing a 401 right before this error was shown in the console. I put a console.log() before the request, and in the success callback. My two logs would show, then the XML5633 message would come up.

Uh, what?

My instincts told me that something was doing a setTimeout() and processing the XML outside of a try/catch. I started doing return statements in the methods that were called to isolate the general region this was coming from. I found the error did not show up if I put a return right before the AJAX request, and showed up when I did a return right after the request. This told me something was happening inside of the request that caused the error.

After some additional digging, I found that in the case of a non-200 HTTP status code there are some rules it goes through to determine how to handle the error response. If it is not a 404 or a 500, it tries to parse the response and look for a relevant error message. It uses jQuery.parseXML() to convert it from a string to a document it can use XPath on.

When I did a return right before the parseXML() call, no error showed up. When I did a return right after, the error showed up. This told me it was happening somewhere inside of the jQuery code. What's strange is that the call to this method was wrapped in a try/catch, the method was throwing an exception, and the browser displayed the exception in the console even though it was explicitly caught.

In that method, jQuery uses the DOMParser object, and it's method parseFromString(). It's call to that method is also wrapped in a try catch, so it seems strange the error was still showing up in the console. This method is a version of my Bottom-Up debugging technique.

I created a Fiddle to test this situation:

try {
    var dp = new DOMParser();
    dp.parseFromString('<a><hr></a>', 'text/xml');
    alert('Parse successful');
catch (e) {

The HTML returned in the AJAX request was actually invalid XML. The HR tag never closed itself off. All browsers should be able to convert <hr> to <hr/> just like <br> is handled like <br/>. Chrome's DOMParser was able to figure this out, but IE's threw an exception.

I'm fine with it throwing an exception. I'm not fine with it showing an error in the console even though it's coming from a call that's inside of two try/catch blocks. It's very difficult to explain to QAs why an error should be logged in one situation but not another. Fixing the HTML to be <hr/> would fix the issue, but I'm sure this will pop up again.

This happened in Internet Explorer 9, 10, and 11. :(

Originally posted on 6/11/2014 at my blog:


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Written By
Software Developer Keyhole Software
United States United States
This member has not yet provided a Biography. Assume it's interesting and varied, and probably something to do with programming.

Comments and Discussions

SuggestionIE-XML5633-monkeypatch Pin
Giorgio Arata14-Jun-14 4:22
professionalGiorgio Arata14-Jun-14 4:22 
Hallo Zachary Gardner,

By simply exploiting conditional compilation I put up a snippet that amends parseFromString first argument, and try to fix singleton tags area, base, br, col, command, embed, hr, img, input, link, meta, param and source adding a slash char where appropriate.

A working implementation of such a workaround, stacked up into the IE-XML5633-monkeypatch.js file, has been shared as Gist on GitHub.

Please, let me know if you find this solution useful for your specific case.

Best regards, Giorgio Arata.

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.