Closed
Bug 645768
Opened 14 years ago
Closed 14 years ago
In quirks mode, tables constructed at the same time as the body's frame don't pick up the body color quirk
Categories
(Core :: CSS Parsing and Computation, defect)
Core
CSS Parsing and Computation
Tracking
()
VERIFIED
FIXED
mozilla7
People
(Reporter: danne.da, Assigned: bzbarsky)
References
()
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.2a1pre) Gecko/20110328 Firefox/4.2a1pre
Build Identifier:
The text on the FIA website renders the text in the table in white instead of the expected black until you right click on the page, then the text will become black.
Reproducible: Always
Steps to Reproduce:
1. Goto http://www.fia.com/en-GB/sport/championships/f1/Pages/season_guide1.aspx
2. Notice the text in the 3 tables are white (expect for the links to the individual GPs).
3. Right click on the page and the text will become black.
![]() |
Assignee | |
Comment 1•14 years ago
|
||
Interesting. I see the text white (including in computed style) until I examine the CSS rules for that table cell. Then it becomes black...
Status: UNCONFIRMED → NEW
Component: General → Style System (CSS)
Ever confirmed: true
QA Contact: general → style-system
![]() |
Assignee | |
Comment 2•14 years ago
|
||
Whatever causes that inner table to not have white text is not happening properly in this testcase. If I take out the <link> or replace it with a <style> the problem goes away.... And if I put the white color on the <body> then the text is white in all browsers(!).
![]() |
Assignee | |
Comment 3•14 years ago
|
||
David, do you have any idea where this quirk is implemented?
![]() |
Assignee | |
Comment 4•14 years ago
|
||
Ok, found it. So the problem here is that we're doing InitialReflow when the stylesheet finishes loading. We're in the middle of frame construction and we end up resolving style for that inner table. But nsHTMLStyleSheet::RulesMatching calls GetBodyColor() which looks for the <body>'s frame, which we don't have yet. So we bail out and don't apply the quirk.
![]() |
Assignee | |
Comment 5•14 years ago
|
||
If we don't have a <body> frame we should consider just resolving a style for the body in this situation...
![]() |
Assignee | |
Comment 6•14 years ago
|
||
The other option is to restyle when the <body> gets a frame. David, thoughts?
![]() |
Assignee | |
Updated•14 years ago
|
Summary: FIA website renders font-color incorrectly → In quirks mode, tables constructed at the same time as the body's frame don't pick up the body color quirk
![]() |
Assignee | |
Comment 7•14 years ago
|
||
And another option is that when we resolve style for a <body> in the frame constructor we tell nsHTMLStyleSheet about the new style...
![]() |
Assignee | |
Comment 8•14 years ago
|
||
Updated•14 years ago
|
Hardware: x86 → All
Version: unspecified → Trunk
![]() |
Assignee | |
Updated•14 years ago
|
Comment 9•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/9439ffe089a1 has this bug in the summary. Should it be fixed?
![]() |
Assignee | |
Comment 10•14 years ago
|
||
Yes, this was fixed by bug 655549.
Assignee: nobody → bzbarsky
Status: NEW → RESOLVED
Closed: 14 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
Comment 12•13 years ago
|
||
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (X11; Linux i686; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0) Gecko/20100101 Firefox/7.0
Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20100101 Firefox/7.0
Verified fixed on Mac OS 10.6, Ubuntu 10.4, Windows XP and Windows 7. I have used the test case provided in comment 8.
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•