606697 - DOMParser chokes on parsing content with XML containing XUL namespace

Status: RESOLVED WONTFIX

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

Description

[Sergey Ilinsky]

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 http://www.amplesdk.com/examples/markup/xul/views/ 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="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.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="http://www.mozilla.org/newlayout/xml/parsererror.xml">XML Parsing Error: 
Location: http://www.amplesdk.com/examples/markup/xul/views/
Line Number 1, Column 106:<sourcetext>&lt;?xml version="1.0"?&gt;&lt;xul:page xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"&gt;&lt;xul:menulist /&gt;&lt;/xul:page&gt;
---------------------------------------------------------------------------------------------------------^</sourcetext></parsererror>

Expected Results:  
<?xml version="1.0"?><xul:page xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"><xul:menulist/></xul:page>

Comment 1

[Sergey Ilinsky]

May have something to do with bug 546857

Comment 2

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

WONTFIX per bug 592829 comment 2.

Comment 3

[Sergey Ilinsky]

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.

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

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.

Comment 5

[Sergey Ilinsky]

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

Comment 6

[Robbert Broersma]

Xopus (an in-browser XML editor, see http://xopus.com) 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.

Comment 7

[Johnny Stenback (:jst)]

Over to sicking, but I'm pretty sure this is a WONTFIX bug by now.

Comment 8

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

Yeah, this is unfortunately WONTFIX. See this thread for all details

http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/3279e68d8966da36#

Specifically:
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 "http://foo.com/mynamespace".

Comment 9

[Unknown W. Brackets]

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

-[Unknown]