Steps to reproduce: open the bug URL. The expected result is "PASS PASS", actual result is "PASS undefined", where undefined comes from r.responseXML.title.
Actually, I do not see how WebKit is wrong here - responseXML is not an HTMLDocument, so it shouldn't have a title property. Hixie, could you perhaps comment on this test? A separate issue (the one that I have originally put in the summary) is that XHTML documents are HTMLDocuments in Firefox, but aren't such in WebKit.
All Documents should be HTMLDocuments (and SVGDocuments, and so forth) according to HTML5. But that isn't yet a standard, I guess. How do you decide what type to make a Document at the moment?
responseXML is always just a Document in WebKit, and its interface is defined in this IDL: <http://trac.webkit.org/projects/webkit/browser/trunk/WebCore/dom/Document.idl>. HTML and SVGDocuments are made such at creation time (using Content-Type if parsing frame content, or explicitly if created via e.g. implementation.createHTMLDocument).
As far as XMLHttpRequest is concerned you return an object which implements the Document interface. Other specifications, such as HTML5, can say that if you implement HTML, the object that implements the Document interface must also implement HTMLDocument. This seems out of scope for XMLHttpRequest to say.
Created attachment 18254 [details] test case Although Document/HTMLDocument relationship in WebKit is still quite different from the one specified in HTML5, we do have document.title on non-HTML documents now.
Comment on attachment 18254 [details] test case r=me
Committed revision 29133.
Mass moving XML DOM bugs to the "DOM" Component.