Closed
Bug 87674
Opened 23 years ago
Closed 23 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•23 years ago
|
Keywords: regression
Whiteboard: [ruletree]
|
||
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
|
Assignee | |
Comment 5•23 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•23 years ago
|
||
Could you explain the change in nsRuleNode? Thanks.
|
|
Assignee | |
Comment 10•23 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•23 years ago
|
||
sr=waterson
|
|
Assignee | |
Comment 12•23 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•