Table color quirk not applied unless doc background specified

RESOLVED FIXED in mozilla0.9.4

Status

()

Core
CSS Parsing and Computation
RESOLVED FIXED
17 years ago
17 years ago

People

(Reporter: fantasai, Assigned: David Hyatt)

Tracking

({regression})

Trunk
mozilla0.9.4
regression
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ruletree])

Attachments

(4 attachments)

(Reporter)

Description

17 years ago
Overview:

	The table color quirk, in which the table's text color is the same as
	that of the document, only works if there is a background specified on
	the <body> element.

Steps to Reproduce:

	Open up testcases in Mozilla. (to be attached shortly)

Actual Results:

	Table color is blue (document color) only in Testcase A.

Expected Results:

	Table color should be blue (document color) in all three testcases.

Tested on Mozilla nightly id=2001062004 and id=2001060308

Additional Information:

	This is a regression introduced between the 2001053104 and 2001060308
	builds. Moreover, there was a bug in the 2001060308 build that caused
	the table color to be that of the user prefs if the background was
	specified on <html> (or :root). Therefore, fixing this bug may not
	lead to expected behavior in Testcase B.

	This bug is probably caused by Hyatt's changes on 2001-05-31,
	specifically because A) background and color data are split and
	                     B) WalkRuleTree doesn't call the
	                        PostResolveCallback function if no properties
	                        were specified for that style struct type.
	The table quirk relies on the DocumentColorRule and the
	DocumentColorRule's color gets set in the BodyFixupRule's
	PostResolveCallback--which doesn't get called, hence the problem.
	AFAICT, anyway.

	David Baron, I'm CCing you because you seem to be involved in a lot of
	related bugs (like bug 77287).
(Reporter)

Comment 1

17 years ago
Created attachment 39956 [details]
Testcase A
(Reporter)

Comment 2

17 years ago
Created attachment 39957 [details]
Testcase B
(Reporter)

Comment 3

17 years ago
Created attachment 39958 [details]
Testcase C
(Assignee)

Comment 4

17 years ago
Yup.
Assignee: pierre → hyatt
Target Milestone: --- → mozilla0.9.3

Updated

17 years ago
Keywords: regression
Whiteboard: [ruletree]

Updated

17 years ago
Blocks: 91672
Target Milestone: mozilla0.9.3 → mozilla0.9.4
(Assignee)

Comment 5

17 years ago
Created attachment 43720 [details] [diff] [review]
Patch to fix bug.
*** Bug 91724 has been marked as a duplicate of this bug. ***
r=dbaron, although it would be nice to be consistent on whether you 
believe we'll be able to avoid crashing when we run out of memory (I tend 
to think we won't, so there's no need to bother with NS_IF_ADDREF rather 
than NS_ADDREF).

Comment 8

17 years ago
Could you explain the change in nsRuleNode? Thanks.

Comment 9

17 years ago
*** Bug 90425 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

17 years ago
There are two types of special style rules that should both be eliminated (the
TableTHRule and the infamous BodyFixupRule).  I have filed bugs to eliminate
both of these rules.  

Until then, these two rules make use of something called a PostResolveCallback,
because they have to tinker with the style data after it has been computed.  The
rule node code contains some optimizations to share computed style data in the
rule tree.  

By adding this check, I ensure that style data is not cached in the rule tree
when a PostResolveCallback wants to monkey with the data.  That way I ensure
that the callback gets invoked every time you resolve style on <body> and on <th>.

The PostResolveCallback was a hack to preserve the BodyFixupRule and the
TableTHRule for the initial landing of 78695.  We should be able to eliminate it  
once the two rules that make use of the feature are removed.

Comment 11

17 years ago
sr=waterson

Updated

17 years ago
Blocks: 91786
(Assignee)

Comment 12

17 years ago
Fixed.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.