Closed Bug 68061 Opened 22 years ago Closed 19 years ago

without wrapping tr in tbody, table does not render correctly in XHTML


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






(Reporter: chrispetersen, Assigned: dbaron)




(Keywords: fixed1.4.1, testcase, xhtml, Whiteboard: [patch])


(4 files)

Build: 2001020608
Platforms: All
Expected Result: Background color should displayed in table
What I got: Background color is only partially displayed. Character data in the TD
is opaque and overlaps background color.

Steps to reproduce

1) Open either test case:



2) In the table_bgcolor_rgb.xml
, the bgcolor attribute appears in the TABLE element.

 In the tr_bgcolor_rgb.xml
, the bgcolor attribute appears in the TR element.

3) Notice that the background color specified is not completely displayed. The
TD 's contents is opaque and covers the background color.
Found out more info about the problem. Each test case has a bgcolor attribute on
the BODY element. A value of "#FFFFFF has been assigned.Removing the bgcolor
attribute from body will allow the background color of the TR/TABLE will display
Keywords: xhtml
I believe it is possible to work around this by using CSS stylesheet.

This bug has been marked "future" because the original netscape engineer
working on this is over-burdened. If you feel this is an error, that you or
another known resource will be working on this bug,or if it blocks your work
in some way -- please attach your concern to the bug for reconsideration.
Target Milestone: --- → Future
Heikki: could please reevaluate this since I think this is what's causing bug 
53944. If it is then bgcolor on tables will be broken for xslt generated pages

Chris: could you please attach the testcases here so that non-netscape people 
can test them, thanks
Keywords: mozilla1.0
Here are the same tests found at
Jonas, would you have the cycles to track this down? It is most likely just a QI
to nsIHTMLDocument somewhere that we could get rid of, or extend it for
nsIXMLDocument as well. Tracking it down is the hard part, and I don't know when
I will have the cycles to work with this.

I don't know a good place to place breakpoints to start with since I have not
looked at the code, but here is one suggestion: place a breakpoint in
nsXMLContentSink::OpenContainer and step in to the code that creates the HTML
content object that has the bgcolor attribute. This way you should be able to
find out what class might be the culprit. Then, place breakpoints in the methods
of that class that might have something to do with this to try and track down
where it happens. The bug might be in the content class, or frame class, or a
combination of both or with bad luck it might be somewhere else. I am pretty
sure the content sink has nothing to do with this, but you could see if the HTML
content sink has some special handling for bgcolor attribute.

You could also ask the table people (karnaze?) what would be a good place to
look at.
Target Milestone: Future → mozilla1.0
Since this does considerably affect rendering of XML/XSL changing severity to
Possible to get this into 0.9.4 ?
Severity: normal → major
The problem is that for XHTML we're not creating the (optional) TBODY element.
For HTML, this is handled by the parser, which does various fix-up for cases
like this. In this case, it inserts a TBODY element between the TABLE element
and the first TR element. Not sure whether we should handle this in the sink our
in the stylesheet (html.css?).
See The relevant bit
is "The TBODY start tag is always required except when the table contains only
one table body and no table head or foot sections."
Lowering severity, there's a workaround: wrap your rows in a TBODY.
Severity: major → normal
Just FYI: XHTML should not create a tbody element in the DOM if it is missing 
from the markup. This is one of the differences between XHTML and HTML. See 
C.11 in
CC karnaze: he says there will be some problems in tables if there is no TBODY...
see bug 30378 for an extended discussion of the tbody problem
Oh, I even noticed that in the xhtml DTD <tr> is a valid child of <table> so we
should defenetly be able to deal with that (at least in xhtml)
Jst, you're right. So the problem is a table layout issue. See also bug 86664
which is very similar, not sure if it's a dupe though.
Assignee: heikki → karnaze
Component: XML → HTMLTables
QA Contact: petersen → amar
er, I meant Jonas ;)
Keywords: testcase
I can't get to the url and the test case works around the problem. Removing the
<tbody>s from the test case doesn't exhibit the problem. Need test cases.
Keywords: testcaseqawanted
*** Bug 86664 has been marked as a duplicate of this bug. ***
Keywords: testcase
Keywords: mozilla0.9.9
my guess that moz should be just creating an anonymous table-group object when
there is no tbody
depends on what you mean by "anonymous table-group object". We can't add a 
tbody node in the DOM since that would break the DOM Core spec. We could 
however add a table-group frame, but i'm not sure if that would help, or if 
there even is such a frame
I was thinking more in terms of this:

I should have said table-row-group and not table-group

it seems that it says:

* If the parent P of a 'table-row' element T is not a 'table', 'inline-table',
or 'table-row-group' element, an object corresponding to a 'table' element will
be generated between P and T.

but it also says

* If a child T of a 'table' element (or 'inline-table') P is not a
'table-row-group', 'table-header-group', 'table-footer-group', or 'table-row'
element, an object corresponding to a 'table-row' element will be generated
between P and T.

I'm not sure if it would help this bug, but that is how moz should be behaving.
doh! Forget what I said. I'm now wondering if we should suggest to the CSS WD to
amend it to make table-row not a child of table.
Moving to Moz 1.1. Engineers are overloaded with higher priority bugs.
Target Milestone: mozilla1.0 → mozilla1.1
As this affects all rendering of XML/XSL I do recommend this for 1.0
changing summary from:
Table/TR bgcolor attribute is not render correctly in XHTML
without wrapping tr in tbody, table does not render correctly in XHTML

I would suggest that whenever a table-row frame is found to be a child of a
table frame, moz create a table-group frame. Though it doesn't follow the CSS2
spec but it does makes things easier and simpler, and I don't think there will
be any visible differences.
Summary: Table/TR bgcolor attribute is not render correctly in XHTML → without wrapping tr in tbody, table does not render correctly in XHTML
Blocks: 30378
No longer blocks: 30378
Blocks: 30378
Depends on: 148810
Keywords: mozilla1.1
Blocks: 154398
Keywords: mozilla1.1mozilla1.3
Blocks: 193529
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: mozilla1.1alpha → ---
Priority: -- → P2
Target Milestone: --- → Future
*** Bug 205481 has been marked as a duplicate of this bug. ***
Blocks: 211114
Blocks: 151996
Bug 211636 explains a good bit of the problem in this bug and the bugs it blocks.
Depends on: 211636
Attached patch patchSplinter Review
Assignee: table → dbaron
Whiteboard: [patch]
Target Milestone: Future → mozilla1.5beta
Attachment #127601 - Flags: superreview?(bzbarsky)
Attachment #127601 - Flags: review?(bzbarsky)
Comment on attachment 127601 [details] [diff] [review]

Please add a comment that calling GetTable like:

nsIConten* tableContent;

(with a pointer to an uninitialized nsIContent*) will most likely crash, ok? 
It's probably safe to assume that won't happen since this is a protected
method, but....
Attachment #127601 - Flags: superreview?(bzbarsky)
Attachment #127601 - Flags: superreview+
Attachment #127601 - Flags: review?(bzbarsky)
Attachment #127601 - Flags: review+
Why?  The out param is initialized to null at the beginning of |GetTable|.
Fix checked in to trunk, 2003-07-12 15:13 -0700.
Closed: 19 years ago
Resolution: --- → FIXED
Attachment #127601 - Flags: approval1.4.x?
*** Bug 205705 has been marked as a duplicate of this bug. ***
Comment on attachment 127601 [details] [diff] [review]

a=asa (on behalf of drivers) for checkin to 1.4 branch.
Attachment #127601 - Flags: approval1.4.x? → approval1.4.x+
Fix checked in to MOZILLA_1_4_BRANCH, 2003-08-08 02:17 -0700.
Keywords: fixed1.4.1
*** Bug 193529 has been marked as a duplicate of this bug. ***
*** Bug 15799 has been marked as a duplicate of this bug. ***
Blocks: 224532
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.