From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020510 BuildID: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc2) Gecko/20020510 I have an XML document with XHTML embedded inside it, which is not rendering new XML elements as I create them. Reproducible: Always Steps to Reproduce: 1. Visit the URL above. 2. In the table, check the x < y box for sets[0] and the JS-XNS Number Test box. 3. Click the Begin Test button. Actual Results: The page adds a few pixels of vertical whitespace and a lot of nodes; no text is visible, though the text nodes are there and have non-empty nodeValue properties. Expected Results: The page adds a table of detailed information. When I manually include the XML elements correctly formatted for this language, they render correctly. I'll be more than happy to provide an alternate example that demonstrates this. DOM Inspector, for elements physically coded into the page, shows those elements having the CSS rules applied to them. The dynamically inserted nodes do not.

To use the testcase in the second attachment, simply click on the button. Actual results: The nodes are added (DOM Inspector confirms this), but not rendered. Expected results: The nodes are added and rendered.

Sorry for the spambug.

Odd... the second testcase (add automatically) works... I see this on Linux too.

Perhaps related to bug 138290? Perhaps not, though. Does "Dump Frames" in viewer show any frames created? (Does "Dump Content" show the right content?)

So... dumping content shows the content. Dumping frames shows no frames. This is confirmed by the "width: auto" inspector shows -- this only happens for block-level elements if they have no frames.

Figuring out when this regressed would be useful.

works on Linux in 2001-12-04-08 nightly broken in 2001-12-07-08 nightly

Long list.... :( http://bonsai.mozilla.org/cvsquery.cgi?date=explicit&mindate=12%2F04%2F2001+04%3A00%3A00&maxdate=12%2F07%2F2001+08%3A00%3A00

Checkins to layout, content, and dom during that period: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=mozilla%2Flayout+mozilla%2Fcontent+mozilla%2Fdom&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2001-12-04+08%3A00&maxdate=2001-12-07+10%3A00&cvsroot=%2Fcvsroot

"The first step to confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- my own words, which I shall eat again. -- if I set: xnsdata { display:block; } the table renders. And of course, you can't have a table inside an inline element (which is the default, and thus the current, styling for <xnsdata>...</xnsdata>). Thanks bz for figuring that out. dbaron, bz says block inside inline is somehow valid; can you confirm and explain that? If it isn't, this bug is INVALID.

Incidentally, the layout of the table's width exactly matches attachment 58841 [details] for bug 111397.

No, blocks are allowed within inlines and we should handle that by breaking lines. We have code to do that, but presumably it's not working quite right.

Ignore comment 13. It's completely wrong.

Mass-reassigning bugs to dom_bugs@netscape.com

So this bug as originally reported got fixed by the fix for bug 233480 (between 2004-02-08-08 and 2004-02-09-08). This testcase still fails in the 2004-02-09-08 build though (but passes on trunk).

That second testcase was fixed by the patch for bug 291902. Which makes sense -- at that point we're properly reconstructing the doc element hierarchy. Marking fixed. Should still add the regression tests.

For my own reference, bug 291902 landed between 2005-10-16-07 and 2005-10-17-07.