8524 - {compat} Nav Quirks not working correctly with bgcolor on table cells

Status: VERIFIED FIXED

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

Description

[Christine Hoffman]

Using 6/18 Viewer.

Bring up the attached file in Viewer. Make sure you are in 'Nav Quirks' mode.
The doc contains a table. The BODY element has a bgcolor value of fuchsia; the
TABLE element has a bgcolor value of lime. In 'standard' mode the border of the
table displays in lime which is correct.

Expected result in 'Nav Quirks' mode: The border should display in fuchsia.

Actual result in 'Nav Quirks' mode: Gecko is laying out the lime table bgcolor
first, and then laying the fuchsia body bgcolor over it. Instead of getting a
solid fuchsia color, the user can see the lime color underlying the fuchsia.
Gecko should be ignoring the table's lime bgcolor.

Comment 1

[Christine Hoffman]

Attachment: To demonstrate problem

Comment 2

[Nicholas Cull]

That's a good test case you have there.

Comment 3

[Péter Bajusz]

Attachment: Better visible testcase

Comment 4

[Péter Bajusz]

Checked this one with 1999-09-04-08 on Win98

The issue is not that simple as the table has:
 - border
 - cellspacing area
 - cell

I've done regression test with Mozilla, NS 4.51 and IE4.
 - Mozilla
   border: table bgcolor
   cellspacing: page bgcolor
 - NS 4.51
   border: page bgcolor
   cellspacing: page bgcolor
 - IE4
   border: page bgcolor
   cellspacing: table bgcolor

So the current behaviour is neighter NS4.51 nor IE4 compatible.

Because the behaviour of Netscape and Explorer is not compatible with each
other, this one should be implemented as the standard dictates.
No quirks please!

Comment 5

[Masatoshi Kimura [:emk]]

According to CSS2 spec. 8.5.3,

|The color of borders drawn for values of 'groove', 'ridge', 'inset',
|and 'outset' depends on the element's 'color' property.
 ( http://www.w3.org/TR/REC-CSS2/box.html#border-style-properties )

At least in standard mode, border color should depends on the 'color',
NOT the 'background-color'.

Mozilla5 handles correctly for the P elements,
but does not handle correctly for the TABLE/TD elements.
I'm using [1999100308] build on WinNT4 (SP5).

Comment 6

[Masatoshi Kimura [:emk]]

Attachment: Testcase for 'inset' and 'outset' border color

Comment 7

[karnaze (gone)]

Moving to M13.

Comment 8

[lah]

As I understand.

1) The *border* shuld be set to the color of the *table*.
2) The *spacing* shuld be set to the background-color of the *table*.
3) Empty cells shuld be set to the background of the *table*

The later two use the background-color of the tables parent right now
- That is wrong but consistent with NAV (but not IE).
- It's also quite anoying ;-)

Don't realy know about the border, gues the collor only makes sens if the
border is solid. Inset and outset shuld be rellative to the background?
Relly dont know her, but it dont rely make sens any other way...

Thanks /Lars

Comment 9

[karnaze (gone)]

mass move to m14.

Comment 10

[Hixie (not reading bugmail)]

Migrating from {css2} to css2 keyword. The {css1}, {css2}, {css3} and {css-moz}
radars should now be considered deprecated in favour of keywords.
I am *really* sorry about the spam...

Comment 11

[ekrock's old account (dead)]

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

Comment 12

[Gervase Markham [:gerv]]

*** Bug 26824 has been marked as a duplicate of this bug. ***

Comment 13

[Christian Mattar]

*** Bug 25337 has been marked as a duplicate of this bug. ***

Comment 14

[karnaze (gone)]

I am about to check in code which fixes the problem in "standard" mode where the 
border color is not the same as the foreground color. 

Mark, -moz-bg-inset is the default border style for a table in quirks mode. It 
doesn't appear to be working as in Nav4.x, although it was created for that 
purpose. It is using the table's background color as its color instead of 
starting at the table's parent and then working up to find the first non 
transparant background color. Fixing this will fix the problem as originally 
reported. I'll attach a test case where the same thing happens on a paragraph.

Comment 15

[karnaze (gone)]

Attachment: border -moz-bg-inset not working as expected

Comment 16

[karnaze (gone)]

Since 26824 and 25337 are marked as duplicates of this, it should be mentioned 
again that the table's background color only shows in the cellspacing when the 
doc type is strict.

Comment 17

[Marc Attinasi]

That is one ugly test case (Fuschia and Lime?!?)... but I'll look at it anyway.

Comment 18

[Marc Attinasi]

The fix is easy: in Quirks Mode the nsStyleUtil::FindNonTransparentBackground 
gets passed a new argument that tells it to start at the parent of the context 
rather than the context passed in. This causes the walk up the chain of parent 
context's looking for an opaque bgcolor just like we want it to. Needs a little 
more testing but that is pretty much it (only the HR and BR element are coupled 
to the nsStyleUtil class so the impact is low, but I need to test the editor 
as well<g>).

Comment 19

[Marc Attinasi]

Fixed. r=karnaze

Comment 20

[Masatoshi Kimura [:emk]]

Mozilla is now using body's background color for the table's border.
However, it's still using table's background color for the table cell's border.
This is not compatible with Nav4.

Comment 21

[Masatoshi Kimura [:emk]]

Attachment: Magnified screenshot: Mozilla rendered left one, Nav4 rendered right one.

Comment 22

[Masatoshi Kimura [:emk]]

Additionaly, -moz-bg border should use the body's background color
 (not parent's one) since Nav4 did so.
I'm reopening this bug.

Comment 23

[Masatoshi Kimura [:emk]]

Attachment: Screenshot: inner table's border should be blue

Comment 24

[Masatoshi Kimura [:emk]]

Attachment: Testcase demonstrating the nested table's bug

Comment 25

[Marc Attinasi]

Just clarifying the summary to help me keep the bugs straight... please forgive 
the spam.

Comment 26

[Marc Attinasi]

Finally, I have a fix for this. Inside of nsCSSRendering.cpp, in the method 
PaintBorder, we check if we are in Quirk mode AND we have a table or tablecell 
display type. If so, we get the HTML element's color by traversing from the 
PresContext to the PresShell to the Document to the RootContent. Then we get the 
Primary Frame for the root context (if it is the HTML or BODY element) and from 
the frame, the style context. From the StyleContext we get the bgColor to use. 

There are some assumptions built in to this solution, most obvious is that the 
root element is the HTML element. It usually (always?) is, and anyway if it is 
not we simply use the bgColor of closest ancestor with a bgColor set. Other 
assumptions that could break include: assuming there is a document, assuming the 
root element has a primary frame, assuming the HTML element has the BODY 
element's style context. These are all true TODAY but this is somewhat volatile.

Checkin pending review...

Comment 27

[Masatoshi Kimura [:emk]]

HR elements should also use the root element's bgcolor in quirks mode.
In my opinion, we should check whether we have a -moz-bg border style insted of 
a dispay type.

Comment 28

[Masatoshi Kimura [:emk]]

Attachment: Testcase about HR elements

Comment 29

[Marc Attinasi]

[e-mail] is right, I missed that in the earlier comment...

In fact, each SIDE of the border can have a different style, so I now check on 
each side if it is moz-bg-inset or moz-bg-outset and then use the BODY element's 
bgcolor for those sides that have moz-bg-nxxx. 

I'll add another testcase showing what happens when the border styles are 
mixed...

Comment 30

[Marc Attinasi]

Attachment: HTML testcase showing some borders using moz-bg-inset and some not

Comment 31

[Marc Attinasi]

Fix checked in: nsCSSRendering.cpp v3.103 r=rods

Comment 32

[Christine Hoffman]

Using 7-13-08 build, verified fixed.