193529 - background-color attribute for table rows not being rendered when constructed with DOM

Status: RESOLVED DUPLICATE of bug 68061

(Core :: Layout: Tables, defect, P3)

Description

[Peter Maly]

User-Agent:       Mozilla (X11; I; Linux 2.0.32 i586)
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.2.1) Gecko/20021130

Attached are 2 testcases of achieving the same thing.  Click on the button
Insert Rows a couple of times to generate several rows of a simple table.  In
the first testcase, javascript creates a onmouseover="this.bgcolor='blue'"
attribute for the table row through the DOM.  In the second testcase, javascript
assigns a callback function to the onmouseover event, which calls a function
highlight2 to set the the background colour of this row to blue via
style="background-color='blue' through DOM.

Neither approaches work, yet they both should.  Both work if you do it on cells
(i.e. TD elements), but not rows (TR elements).

At the bottom of each testcase, you get the expected behaviour.  The static
version works just fine.

Reproducible: Always

Steps to Reproduce:
See details
Actual Results:  
see details

Expected Results:  
see details

This appears not to have anything with the onmouseover event, because I can set
other attributes via same code in both test cases.  This is definitely 
background-color for table rows not being rendered when it gets constructed
through DOM.

Comment 1

[Peter Maly]

Attachment: testcase1 to reproduce bug

just move the mouse over the expected table and the constucted table from
hitting Insert Rows button.

Comment 2

[Peter Maly]

Attachment: testcase2 of the same bug

just move the mouse over the expected table and the constucted table from
hitting Insert Rows button.

Comment 3

[Boris Zbarsky [:bzbarsky]]

The problem is that you're appending <tr> elements directly to the <table>
element instead of the <tbody> inside the <table>... If you append the table
rows in the right place, things work.

That said, table layout _should_ be coping with a DOM like that (without a
tbody).  It could happen in XHTML, after all....  (if you could write such an
XHTML testcase with both the test table and the "expected" table having no
<tbody>, that would be great).

I suspect that something in the frame construction gets messed up, which leads
to issues.

Seeing this on Linux too.

Comment 4

[Chris Casciano]

... and 1.3b OS X

Comment 5

[Peter Maly]

Actually both testcases that I submitted have no <tbody> in either the expected
or  in the dynamically created table.  However, after reading what you said, I
fired up the DOM inspector for kicks, and I noticed that Mozilla automatically
puts in the <tbody> tag, and sticks the rows under <tbody> for the static table.

Also I hacked the testcase1 to append to <tbody> and it works as you said it would.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Yeah, in HTML the <tbody> tag is implied (the opening and closing tags are
optional, but <tr> can't be a child of <table>, so the parser auto-opens the
<tbody>).  This is not the case in XHTML, which is why I'd love an XHTML
testcase (as application/xhtml+xml)

Comment 7

[Peter Maly]

Attachment: XHTML version of testcase 1

Here is the XHTML version of testcase 1 with appending the the rows directly to
<table> and not <tbody>.    File passed xmllint and checks out.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Attachment: same, with the right namespace and no JS

As this testcase shows, this is purely a table layout problem.

Comment 9

[Boris Zbarsky [:bzbarsky]]

tables.

Comment 10

[Bernd]

is this a dupe of bug 68061 ? or does it depend on bug 68061?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Fixing that bug would likely fix this.....

Comment 12

[Chris Casciano]

this looks fixed now... care to comment bz?

Comment 13

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

This was fixed by bug 68061 because we were mapping the style for the BODY into
the table cell instead of the style for the TABLE.

*** This bug has been marked as a duplicate of 68061 ***