Closed
Bug 87674
Opened 24 years ago
Closed 24 years ago
Table color quirk not applied unless doc background specified
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
RESOLVED
FIXED
mozilla0.9.4
People
(Reporter: fantasai.bugs, Assigned: hyatt)
References
Details
(Keywords: regression, Whiteboard: [ruletree])
Attachments
(4 files)
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).
|
||
Updated•24 years ago
|
Keywords: regression
Whiteboard: [ruletree]
|
||
Updated•24 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
|
Assignee | |
Comment 5•24 years ago
|
||
*** 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•24 years ago
|
||
Could you explain the change in nsRuleNode? Thanks.
|
|
Assignee | |
Comment 10•24 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•24 years ago
|
||
sr=waterson
|
|
Assignee | |
Comment 12•24 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•