Closed Bug 605087 Opened 15 years ago Closed 15 years ago

Parse error when XML document contains XUL namespaced elements

Categories

(Core :: XML, defect)

defect
Not set
normal

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.