1279946 - XMLHttpRequest with "document" responseType returns XMLDocument not HTMLDocument

Status: RESOLVED INCOMPLETE

(WebExtensions :: Request Handling, defect, P3)

Description

[code.maker]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0
Build ID: 20160613030258

Steps to reproduce:

XHR load of a valid HTML5 doc from a WebExtensions project's local resource folder, using responseType of "document".


Actual results:

HTML5 doc loaded features self-closing HTML5 void elements (no '/>').

Loaded object appears to be XMLDocument and as such returns childNodes of NodeList[2], element 0 contains "XMLStylesheetProcessingInstruction", element 1 contains XML Parsing Error representing first encountered parse error (e.g: "mismatched tag. Expected </link>...")

Encountered these errors for parsed <link>, <meta> and <img> lines, all of which are HTML5 void elements so don't require closing.

This wouldn't be a problem if the doc were parsed as HTML5, not XML.


Expected results:

Valid HTML5 document obtained using request responseType of "document" should be returned as parsed HTMLDocument object, not XMLDocument.

Comment 1

[code.maker]

(In reply to code.maker from comment #0)
> User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0)
> Gecko/20100101 Firefox/50.0
> Build ID: 20160613030258
> 
> Steps to reproduce:
> 
> XHR load of a valid HTML5 doc from a WebExtensions project's local resource
> folder, using responseType of "document".
> 
> 
> Actual results:
> 
> HTML5 doc loaded features self-closing HTML5 void elements (no '/>').
> 
> Loaded object appears to be XMLDocument and as such returns childNodes of
> NodeList[2], element 0 contains "XMLStylesheetProcessingInstruction",
> element 1 contains XML Parsing Error representing first encountered parse
> error (e.g: "mismatched tag. Expected </link>...")
> 
> Encountered these errors for parsed <link>, <meta> and <img> lines, all of
> which are HTML5 void elements so don't require closing.
> 
> This wouldn't be a problem if the doc were parsed as HTML5, not XML.
> 
> 
> Expected results:
> 
> Valid HTML5 document obtained using request responseType of "document"
> should be returned as parsed HTMLDocument object, not XMLDocument.

Comment 2

[code.maker]

According to W3C HTML5 differences doc, the XHR with "document" responseType should be aiming to load/parse to build a Document object, not HTMLDocument. See: https://www.w3.org/TR/2012/WD-html5-diff-20120329/#document-extensions

This overall issue reported is a bit more pervasive when codebases rely, not on the self-closing tags as in-document data, but on the use of Document interface properties such as Document.body to r/w the loaded document object.


(aside; sorry about the previous comment #1 that I made - I didn't realise that refreshing the page would post the comment!)

Comment 3

[code.maker]

Some further reference on why the Document object, as per my above comment: 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=22960
https://bugzilla.mozilla.org/show_bug.cgi?id=897815

Comment 4

[code.maker]

Also:

https://bugzilla.mozilla.org/show_bug.cgi?id=1276438 (Document.body incremented on incorrect interface)

But this is a parser issue too no?

And now it sit back!

Comment 5

[ovidiu boca[:Ovidiu]]

This should depends on https://bugzilla.mozilla.org/show_bug.cgi?id=897815?

Comment 6

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

This seems to work fine at <http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4273>; there may be issues with your setup that cause us to think you want it treated as XML.

Comment 7

[code.maker]

(In reply to :Ms2ger from comment #6)
> This seems to work fine at
> <http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4273>; there
> may be issues with your setup that cause us to think you want it treated as
> XML.


Hi, thanks for coming in on this issue. I don't want it treated as XMLDocument. 

I believe that the load of "document" response type, should load as Document DOM api object (https://developer.mozilla.org/en/docs/Web/API/Document) if the document source of input for the XHR load is an HTML5 document.

Code I use in WebKit/Blink does this (XHR load as Document for document response type), but Firefox loads an XMLDocument with the <html> element as firstElementChild of that XMLDocument object... if not everywhere, then at least when loading local html5 resources from a WebExtension product's local file system.


Further Firefox doesn't add head and body properties to the output object, which the WebKit/Blink implementations correctly do (although they correctly load a Document object, not XMLDocument object, in this use case).


1) So in part Ovidiu Boca (see comment 5) is correct, this depends on https://bugzilla.mozilla.org/show_bug.cgi?id=897815.

2) Yet I also wonder if the parser implementation requires implementation adjustments to detect the document as HTML5, parse as such (e.g. self-closing tags) and build the correct output object.


If the input source file were xhtml, xml or svg, then Firefox should do what it does now, creating an output XMLDocument (https://developer.mozilla.org/en/docs/Web/API/XMLDocument).

The output objects of SVGDocument and HTMLDocument are non-standard and should not be used. Other browser platforms have-moved/are-moving away from these, to producing a Document object in this use case.

Comment 8

[Andrew Overholt [:overholt]]

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/4273 gives me an HTMLDocument, too. What do you get?

Comment 9

[Andrew Overholt [:overholt]]

Looking at this older untriaged bug, I'm wondering if there's something specific to Web Extensions here (see "XHR load of a valid HTML5 doc from a WebExtensions project's local resource folder, using responseType of "document"." from comment 0).

Comment 10

[Kris Maglione [:kmag]]

The document type depends on the content type of the URL being loaded. If you want it to parse as HTML, you can call xhr.overrideMimeType("text/html").

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

A needinfo is requested from the reporter, however, the reporter is inactive on Bugzilla. Closing the bug as incomplete.

For more information, please visit BugBot documentation.