Apprunner is crashing when loading a dialog containing a table. This makes it imposible to do editor dialog work. Here's sample XUL to test: <?xml version="1.0"?> <?xml-stylesheet href="xul.css" type="text/css"?> <!DOCTYPE window> <xul:window width="380" height="240" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:xul ="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" > <table xmlns="http://www.w3.org/TR/REC-html40"> </table> </xul:window> Here's the stack: NTDLL! 77f76148() nsDebug::Assertion(char * 0x01d5d05c, char * 0x01d5d04c, char * 0x01d5d01c, int 1974) line 140 + 13 bytes RDFXULBuilderImpl::AddAttribute(nsIContent * 0x01547dbc, nsIRDFResource * 0x01448a80, nsIRDFNode * 0x01448ed0) line 1974 + 38 bytes RDFXULBuilderImpl::CreateHTMLElement(nsINameSpace * 0x015415f0, nsIRDFResource * 0x01545c50, nsIAtom * 0x013a3ae0, nsIContent * * 0x0012dc98) line 1645 + 38 bytes RDFXULBuilderImpl::CreateElement(nsINameSpace * 0x015415f0, nsIRDFResource * 0x01545c50, nsIContent * * 0x0012dc98) line 1527 + 29 bytes RDFXULBuilderImpl::AppendChild(nsINameSpace * 0x015415f0, nsIContent * 0x01538f00, nsIRDFNode * 0x01545c50) line 1412 + 45 bytes RDFXULBuilderImpl::CreateContents(RDFXULBuilderImpl * const 0x014fa7d0, nsIContent * 0x01538f00) line 607 + 30 bytes XULDocumentImpl::CreateContents(XULDocumentImpl * const 0x014fa124, nsIContent * 0x01538f00) line 2092 + 16 bytes RDFElementImpl::EnsureContentsGenerated() line 2428 + 51 bytes RDFElementImpl::ChildCount(const RDFElementImpl * const 0x01538f00, int & 33967788) line 1414 + 11 bytes nsCSSFrameConstructor::ProcessChildren(nsIPresContext * 0x014fbac0, nsIContent * 0x01538f00, nsIFrame * 0x01547380, nsAbsoluteItems & {...}, nsFrameItems & {...}, nsAbsoluteItems & {...}, nsAbsoluteItems & {...}, int 1) line 520 nsCSSFrameConstructor::ConstructDocElementFrame(nsIPresContext * 0x014fbac0, nsIContent * 0x01538f00, nsIFrame * 0x01546eb0, nsIStyleContext * 0x020444d8, nsIFrame * & 0x014fa120, nsAbsoluteItems & {...}) line 1728 nsCSSFrameConstructor::ContentInserted(nsCSSFrameConstructor * const 0x01531770, nsIPresContext * 0x014fbac0, nsIContent * 0x00000000, nsIContent * 0x01538f00, int 0) line 3756 StyleSetImpl::ContentInserted(StyleSetImpl * const 0x015316e0, nsIPresContext * 0x014fbac0, nsIContent * 0x00000000, nsIContent * 0x01538f00, int 0) line 748 PresShell::InitialReflow(PresShell * const 0x01531840, int 9105, int 6795) line 876

Fixed.

I only see two comments in this bug, yet it appears to have been fixed then reopend. What's going on?

A QueryInterface is being done to nsIXMLContent in order to handle namespace stuff. HTML content doesn't implement this interface, and so an assert is hit.

Are you really allowed to put xmlns declarations on an HTML element?

Charlie, I think this bug is invalid re: Vidur's post on n.p.m.layout. news://news.mozilla.org/37251569.431DCE4%40netscape.com It should be fairly easy to work around by either declaring HTML to be the default namespace on an enclosing element, or by explicitly marking elements with the html namespace.

Chris: I don't get your first suggestion: "declaring HTML to be the default namespace on an enclosing element,..." Isn't that what this line does (this is the line that causes the bug)? <table xmlns="http://www.w3.org/TR/REC-html40">

Sorry 'bout that. Let me be a bit clearer: <xul:window xmlns="http://www.w3.org/TR/REC-html40" ...> <table> <!-- 'table' is now in the html namespace --> ...

marking verified per developers input.

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.