Closed Bug 606697 Opened 13 years ago Closed 13 years ago

DOMParser chokes on parsing content with XML containing XUL namespace


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

Windows Vista
Not set



Tracking Status
blocking2.0 --- -


(Reporter: castonet, Assigned: sicking)




User-Agent:       Mozilla/5.0 (Windows NT 6.0; rv:2.0b8pre) Gecko/20101023 Firefox/4.0b8pre
Build Identifier: Minefield 4.0b8pre

The issue (see simple testcase in "Steps to reproduce") introduced in the recent version of Gecko demonstrates erratic behavior of core DOMParser which treats XML string with XUL fragments specially without a reason.

This issue breaks Ample SDK JavaScript UI Framework that implements XUL client-side cross-browser (see for example).

Reproducible: Always

Steps to Reproduce:
1. Run code (on a page served from some HTTP server, also local):
alert(new XMLSerializer().serializeToString(new DOMParser().parseFromString('<?xml version="1.0"?><xul:page xmlns:xul=""><xul:menulist /></xul:page>', "text/xml")))

Actual Results:  
<?xml version="1.0" encoding="UTF-8"?>

<?xml-stylesheet href="chrome://global/locale/intl.css" type="text/css"?>

<parsererror xmlns="">XML Parsing Error: 
Line Number 1, Column 106:<sourcetext>&lt;?xml version="1.0"?&gt;&lt;xul:page xmlns:xul=""&gt;&lt;xul:menulist /&gt;&lt;/xul:page&gt;

Expected Results:  
<?xml version="1.0"?><xul:page xmlns:xul=""><xul:menulist/></xul:page>
May have something to do with bug 546857
WONTFIX per bug 592829 comment 2.
Closed: 13 years ago
Resolution: --- → WONTFIX
DOMParser is an API that parses abstract XML into DOM. It must not have any notion of XML any applience and must not create any objects of specific type (XUL objects or XHTML objects etc.) but use simple DOM Core objects. If I wanted to create DOM XUL, I should have imported the core DOM XML structure into DOM XUL - and this is exactly where the new restriction should have been applied at.

I could also agree with the way the issue is solved if previously I had to use something like:
new DOMParser().parseFromString(xml, "application/vnd.mozilla.xul+xml")

However DOMParser chokes on parsing general-form XML.
Resolution: WONTFIX → ---
This is still WONTFIX for now.  Remote XUL was disabled by forbidding the creation of nodes in that namespace.  This is a bug, but it's not one that is believed to be cost effective to fix.
This is not OK indeed, as it cancels some great (3 years) effort to bring XUL technology to all browsers (XUL is just one of [still major] UI technologies enabled in Ample SDK).

Also, the issue is not simply "a bug", but "the bug" since it reveals some major flow in Gecko core and it should not be just put on WONTFIX but scheduled for resolution (sooner or later).
blocking2.0: --- → ?
Ever confirmed: true
Xopus (an in-browser XML editor, see also uses XUL for UI declarations, which is rendered using our engine as HTML in all types of browsers.

And then there are some customers that edit basic XUL-documents using our editor. Not rendering XUL is one thing, but this should never influence parsing nodes in that namespace.

This bug prevents Firefox 4 starting our upcoming XUL UI based Xopus release, and prevents authors from creating XUL-interfaces using our latest release. Sergey, many thanks for bringing this to our attention.
Over to sicking, but I'm pretty sure this is a WONTFIX bug by now.
Assignee: nobody → jonas
Yeah, this is unfortunately WONTFIX. See this thread for all details

Q: Why can't I create elements in the XUL namespace?
A: It would create significant complexities in our codebase to allow
this. The problem is that a lot of the XUL implementation lives outside
the XUL element class itself. Most of this code today checks if an
element is a XUL element by checking the namespace. All this code would
have to check if the element is a "real" XUL element, or just a normal
element with a XUL namespace. There are literally over a hundred such
locations today, and more are added all the time. We'd be sure to miss a
place or two which would introduce exactly the type of security bugs
we're trying to remove by disabling XUL/XBL.
We recommend that you instead use another namespace and use the same
fallback shim for Firefox as for other browsers.

Is there a reason you couldn't simply use another namespace? Note that even if we were to fix this bug, it won't be "XUL elements" that are instantiated, but rather elements with no intrinsic look or behavior. I.e. they would act like elements in a random namespace like "".
Closed: 13 years ago13 years ago
Resolution: --- → WONTFIX
(In reply to comment #8)

FWIW, the only problem I can think of, realistically, is a web-based XML editor that happens to support XUL files (no more specially than any other XML file.)

Such an editor would be required to alter the data stream before parsing and after serializing to be able to edit XUL namespaced files.  Otherwise it would die on XUL files (most likely unknowingly.)

Probably not a big deal, and certainly not as important as the security impact, but just answering the question.

blocking2.0: ? → final+
blocking2.0: final+ → -
You need to log in before you can comment on or make changes to this bug.