773259 - nsIDOMParser.parseFromString fails with XUL documents

Status: NEW

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

Description

[Alexandre Poirot [:ochameau]]

I wasn't able to get `parseFromString` to work with XUL documents.

Here is a scratchpad test case:
  var parser = Components.classes["@mozilla.org/xmlextras/domparser;1"]
               .createInstance(Components.interfaces.nsIDOMParser);
  var str = 
    '<?xml version="1.0" ?>\n' +
    '<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">\n' +
    '</window>';

  parser.parseFromString(str, "application/xml");

Here parseFromString fires an error message in console, and the returned document is a parseerror document:
  Line : 2, Column : 79
  Source Code :
  <window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">


And if I use real XUL mimetype:
  parser.parseFromString(str, "application/vnd.mozilla.xul+xml");

I get following exception:
  Component returned failure code: 0x80004001 (NS_ERROR_NOT_IMPLEMENTED) [nsIDOMParser.parseFromString]


My goal was to be able to create an empty XUL document instance without having to create an iframe in the hidden window, nor loading any hidden document somehow.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Sicking might remember how we handle XUL in this case.

Comment 2

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

Did this ever work well? Hasn't it always been a problem that the document instantiated by the DOMParser was never a real XULDocument?

Anyway, we might need to call document->ForceEnableXULXBL(); if mPrincipal is the system principal. Similar to what we do in XHR here:

http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#2292

Comment 3

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

Ah, but if we instantiate a real XUL document then things should "just work". See

http://mxr.mozilla.org/mozilla-central/source/content/xul/document/src/nsXULDocument.cpp#219

So I think the proper fix is to make sure that we instantiate a real XUL document. A lot of XUL things don't work properly if you don't have a real XUL document anyway.

Comment 4

[Henri Sivonen (:hsivonen)]

If we make it possible to generate XUL nodes using the DOMParser, I think it should be opt-in so that extensions don't accidentally (when they parse untrusted data) end up with XUL nodes that we might not have tested to work correctly in a "loadAsData" context.

That is, if we allow the creation of XUL document with XUL and XBL enabled, I think it should only happen if the mime type parameter to DOMParser is the XUL mime type.

Comment 5

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

Only enabling it for XUL mime types sounds like a good idea to me.

Which means that the code in comment 0 wouldn't work. But would work if you replace the mimetype with the "text/xul".

Comment 6

[Henri Sivonen (:hsivonen)]

(In reply to Jonas Sicking (:sicking) from comment #5)
> Which means that the code in comment 0 wouldn't work. But would work if you
> replace the mimetype with the "text/xul".

"application/vnd.mozilla.xul+xml", rather.

http://www.iana.org/assignments/media-types/application/vnd.mozilla.xul+xml

Comment 7

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