942138 - xhr2 responseType='document' fails on local pages

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P5)

Description

[christoph.burgmer]

Attachment: Simple testcase behaving correctly when loaded through a webserver, but failing when loading via file:// URL

Loading an HTML document via XHR2 with `responseType="document"` throws an XML parsing error when accessing a local URL (`file://`). See attached test case.

I would expect the parsed Document object instead, similar to the behaviour in Chrome & Safari, or just as Firefox behaves with documents loaded via HTTP.

I can narrow down the issue to the loaded file being requested through a `file://` URL as a local HTML page triggering a request through HTTP (via CORS) works correctly.

Additionally this XHR2 feature does not work with SlimerJS (with Firefox 24) for both file *and* HTTP urls, so this issue might not be simply correlated to the target's origin protocol.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Are you loading a local HTML file or a local XML file?

I believe XHR to file:// will assume that it should parse as XML, since there are no reliable MIME types to be had for file:// URIs.  So if you're loading a local HTML file but parsing with the XML parser, you could get XML parse errors.

Does using overrideMimeType("text/html") make it work for you?

> Additionally this XHR2 feature does not work with SlimerJS (with Firefox 24) for both
> file *and* HTTP urls

Can you point to an HTTP url showing this issue?

Comment 2

[christoph.burgmer]

> Are you loading a local HTML file or a local XML file?

I am loading a local HTML file. Although as this is going to be a generic interface the module does not know beforehand whether it's HTML or XHTML.

> I believe XHR to file:// will assume that it should parse as XML, since there are no reliable MIME types to be had for file:// URIs.  So if you're loading a local HTML file but parsing with the XML parser, you could get XML parse errors.

Understood. However, when opening local pages in the browser, files ending in '.html' by default are interpreted as HTML and ending with '.xhtml' as XHTML. Maybe XHR could follow a similar route?

> Does using overrideMimeType("text/html") make it work for you?

Yes, it actually does.

As a workaround I guess this will not do, as I would also want to accept XHTML documents.

> > Additionally this XHR2 feature does not work with SlimerJS (with Firefox 24) for both
> > file *and* HTTP urls

As it turns out this is connected to my specific setup and the homebrew webserver not sending a content-type, ergo same issue.

Comment 3

[Boris Zbarsky [:bzbarsky]]

> Maybe XHR could follow a similar route?

It could, but at the expense of not being able to parse as XML all sorts of stuff that the browser wouldn't think is XML when you load it in the URL bar.  The tradeoff is unclear, since the XML behavior for local files has been there for a very long time and HTML parsing in XHR is pretty new.  So there would be a good chance of breaking existing things to enable the new functionality.  :(

Here's what the spec at https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#response-entity-body-0 has to say:

  The response MIME type is the MIME type the Content-Type header contains excluding any
  parameters and converted to ASCII lowercase, or null if the response header can not be
  parsed or was omitted.  The override MIME type is initially null and can get a value
  if overrideMimeType() is invoked. Final MIME type is the override MIME type unless
  that is null in which case it is the response MIME type. 

so in this case the response MIME type is null (since there is no Content-Type header in this case), there is no override MIME type, so the final MIME type ends up null.

Then https://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#document-response-entity-body says:

  3. If final MIME type is not null, text/html, text/xml, application/xml, or does not
     end in +xml, return null. 
  4. If responseType is the empty string and final MIME type is text/html, return null. 

we get past here, because our final mime type is null.

  5. If final MIME type is text/html, run these substeps: 

not relevant to us, since our final MIME type is null.

  6. Otherwise, let document be a document that represents the result of parsing the
     response entity body following the rules set forth in the XML specifications. 

which is what we do.

>As a workaround I guess this will not do, as I would also want to accept XHTML
> documents.

Would they be XHTML documents that can't be parsed correctly with an HTML parser?  As in, ones not complying with appendix C?

Comment 4

[christoph.burgmer]

I understand the dilemma here.

> >As a workaround I guess this will not do, as I would also want to accept XHTML
> > documents.
> 
> Would they be XHTML documents that can't be parsed correctly with an HTML parser?  As in, ones not complying with appendix C?

AFAIK embedded JS mustn't be quoted (<, ...) in HTML pages, while it must be quoted in XHTML pages (&lt;, ...). I believe this is described in http://www.w3.org/TR/xhtml1/guidelines.html#C_12.

CDATA sections quoted in JS comments could help there, but again I am looking for a generic solution as I do not know what my users will input.

Comment 5

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.