In jQuery 1.4.1, line 5185:

1.         var ct = xhr.getResponseHeader("content-type") || "",
               xml = type === "xml" || !type && ct.indexOf("xml") >= 0,
               data = xml ? xhr.responseXML : xhr.responseText;
   
           if ( xml && data.documentElement.nodeName === "parsererror" ) {
               jQuery.error( "parsererror" );
           }
   
   
   
   
   
   
   
   
   

Under IE7, when running an HTML document locally, and retrieveing an XML resource in the same folder with XMLHttpRequest, the XML is not automatically parsed, and the responseXML.documentElement is null.
When checking documentElement.name for "parsererror", an error is raised and caught by the calling function, also as "parsererror". This prevents the success callback from ever running.
The same thing appears to happen when the content-type is 'application/atom+xml' (Trac #2949 and #4958)
There is a workaround at Specifying the Data Type for AJAX Requests, of setting the dataType option to 'text'.
Perhaps it would be better to check if the documentElement is null, and call the loadXML method if it is.
On non-IE browsers, where loadXML is not available, an error will be raised and caught as before.

1. if ( xml ) {
    if (data.documentElement === null && data.parseError.errorCode === 0) {
    data.loadXML(xhr.responseText);
    }
    if ( data.documentElement.nodeName === 'parsererror' ) {
    jQuery.error('parsererror');
    }
   }
   
   
   
   
   
   
   
   

A check for a parserError (another IE-specific method) is needed, just in case the documentElement is null because there already was an failed attempt to parse the response as XML.
(As an aside, and I know this is an edge case, what happens when the top-level element in the XML is 'parsererror'? That would falsely be perceived as an error.)