144004 - {ib}CSS styling not applying to DOM-created Element nodes?

Status: RESOLVED FIXED

(Core :: DOM: CSS Object Model, defect)

Description

[Alex Vincent [:WeirdAl]]

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.

Comment 1

[Alex Vincent [:WeirdAl]]

Attachment: CSS style sheet (part 1 of 2 part testcase)

Comment 2

[Alex Vincent [:WeirdAl]]

Attachment: XML document for adding nodes after onload (part 2 of 2 part testcase)

Comment 3

[Alex Vincent [:WeirdAl]]

Attachment: same XML document, except the second table is added automatically

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.

Comment 4

[Alex Vincent [:WeirdAl]]

Attachment: same XML document, correct file this time

Sorry for the spambug.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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

Comment 6

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Perhaps related to bug 138290?  Perhaps not, though.

Does "Dump Frames" in viewer show any frames created?  (Does "Dump Content" show
the right content?)

Comment 7

[Boris Zbarsky [:bzbarsky]]

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.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Figuring out when this regressed would be useful.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 12

[Alex Vincent [:WeirdAl]]

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

Comment 13

[Alex Vincent [:WeirdAl]]

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

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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.

Comment 15

[Alex Vincent [:WeirdAl]]

Ignore comment 13.  It's completely wrong.

Comment 16

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 17

[Boris Zbarsky [:bzbarsky]]

Attachment: Slightly modified testcase

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

Comment 18

[Boris Zbarsky [:bzbarsky]]

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.

Comment 19

[Boris Zbarsky [:bzbarsky]]

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

Comment 20

[Boris Zbarsky [:bzbarsky]]

Attachment: Regression tests