Closed
Bug 605087
Opened 15 years ago
Closed 15 years ago
Parse error when XML document contains XUL namespaced elements
Categories
(Core :: XML, defect)
Core
XML
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: neil, Unassigned)
References
()
Details
The following warnings are also generated:
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file content/xml/document/src/nsXMLContentSink.cpp, line 506
WARNING: NS_ENSURE_SUCCESS(result, result) failed with result 0x80040111: file content/xml/document/src/nsXMLContentSink.cpp, line 1022
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file intl/strres/src/nsStringBundle.cpp, line 258
(The last one is because there is no description for the XML parse error.)
Interestingly there is no parse error when the XML document root is a XUL element. However you do instead get extra assertions and warnings:
###!!! ASSERTION: Can only call this on frames that have been reflowed: '!(GetStateBits() & NS_FRAME_FIRST_REFLOW)', file layout/generic/nsTextFrameThebes.cpp, line 2176
###!!! ASSERTION: Can only call this on frames that have been reflowed: '!(GetStateBits() & NS_FRAME_FIRST_REFLOW)', file layout/generic/nsTextFrameThebes.cpp, line 2176
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80040111: file content/xml/document/src/nsXMLContentSink.cpp, line 506
WARNING: NS_ENSURE_SUCCESS(result, result) failed with result 0x80040111: file content/xml/document/src/nsXMLContentSink.cpp, line 1022
WARNING: NS_ENSURE_TRUE(rootCont) failed: file content/xml/document/src/nsXMLPrettyPrinter.cpp, line 173
WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80004005: file intl/strres/src/nsStringBundle.cpp, line 258
###!!! ASSERTION: Can't create document accessible!: 'docAcc', file accessible/src/base/nsAccDocManager.cpp, line 354
WARNING: NS_ENSURE_TRUE(hWnd) failed: file accessible/src/msaa/nsAccessibleWrap.cpp, line 1595
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".
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•