Bug 10909 – Hixie's XMLHttpRequest/018.html test fails

• Status: RESOLVED
• Resolution: FIXED
• Component: DOM

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

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.

[Ian 'Hixie' Hickson]

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?

[Alexey Proskuryakov]

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).

[Anne van Kesteren]

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.

[Alexey Proskuryakov]

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.

[Darin Adler]

Comment on attachment 18254 [details]
test case

r=me

[Alexey Proskuryakov]

Committed revision 29133.

[Lucas Forschler]

Mass moving XML DOM bugs to the "DOM" Component.