Click here to Skip to main content
Click here to Skip to main content

Tagged as

Go to top

IE XML5633 Error when using jQuery.parseXML()

, 11 Jun 2014
Rate this:
Please Sign up or sign in to vote.
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) {
    alert(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: zgardner.us.

License

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

Share

About the Author

Zachary Gardner
Software Developer Keyhole Software
United States United States
No Biography provided
Follow on   Twitter

Comments and Discussions

 
SuggestionIE-XML5633-monkeypatch PinprofessionalGiorgio Arata14-Jun-14 3:22 

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

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

| Advertise | Privacy | Mobile
Web04 | 2.8.140916.1 | Last Updated 11 Jun 2014
Article Copyright 2014 by Zachary Gardner
Everything else Copyright © CodeProject, 1999-2014
Terms of Service
Layout: fixed | fluid