106110 - DOMParser parseFromString does not load stylesheet data

Status: RESOLVED INVALID

(Core :: XML, defect)

Description

[Peter Wilson]

DOMParser.parseFromString does not load stylesheet data for an XUL document.
If I load an XUL document containing xml-stylesheet PI's the sylesheet 
structures (available through the nsIDocumentStyle interface) return a length of 
zero. The stylesheets are being processed as this was the cause of bug #78622 
(which is now fixed) - the data is just not available.

If I look at the same document loaded by the browser the nsIDocumentStyle 
interface return the correct data.
Test case to follow.

Comment 1

[Peter Wilson]

Attachment: xml file for test case

Comment 2

[Peter Wilson]

Attachment: javascript for test case

Comment 3

[Peter Wilson]

Attachment: file handling javascript for test case

Comment 4

[Peter Wilson]

Attachment: utility javascript for test case

Comment 5

[Asa Dotzler [:asa]]

->XUL?

Comment 6

[John Morrison]

Loading a XUL file via DOMParser means that it is just plain old XML (since 
DOMParser only knows XML).

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Um, jrgm, why did you change the XUL file to XML mime type & name?

Comment 8

[John Morrison]

I guess I was just trying to emphasize the point (correct me if I'm wrong) that
when you load a XUL file with the DOMParser, it is no different than any other 
XML file; the elements <window>, <script>, and <button> could be elements 
<larry>, <curly> and <moe> for all the DOMParser knows. (right?)

So, while it is "XUL" when that file is loaded as chrome in the mozilla 
browser, it is "XML" when loading with the DOMParser.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Could someone attach a self-contained testcase (as a zip if need be) so that
testing this does not involve reassembling things and renaming files to the
right names?

Comment 10

[Jason Barnabe (np)]

This applies to XHTML documents loaded from DOMParser as well. I've updated the URL field to some JavaScript code that parses an XHTML document containing an xml-stylesheet processing instruction, an html:link element, and an html:style element. It then alerts the length of document.styleSheets.length. It should be 3, but it's 0.

Comment 11

[Boris Zbarsky [:bzbarsky]]

We should wontfix this, imo.  DOMParser shouldn't be loading external resources.

Comment 12

[Jason Barnabe (np)]

I agree that it shouldn't load external resources (or at least by default), but the code I gave uses data URLs.

Comment 13

[Boris Zbarsky [:bzbarsky]]

That's still an external resource.

I don't want to start special-casing data URIs, and other URI types that "don't actually hit the network" (javascript:?  about:?  chrome:? res:? file:?).  Especially because then we'd need to have this pervasively through the codebase (e.g. if a sheet from data: @imports a sheet we'd need to check for whether it's http: or data: or not, etc, etc).

Right now the conceptual model is simple: you get a raw DOM with no external resources loaded.  If you want them loaded, use an <iframe>.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Agreed, this is by design. Data-document such as the one produced by the DOMParser should not attempt to load uris.

Comment 15

[Jason Barnabe (np)]

What about style elements?

Comment 16

[Boris Zbarsky [:bzbarsky]]

Data documents disable all processing of anything other than parsing the DOM.  That means no XBL bindings, no CSS loading (inline or not), no script loading (inline or not).  The CSS loader and script loader are explicitly disabled in this case; see http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsDocument.cpp&rev=3.765&mark=1445,1448#1438