Closed
Bug 181336
Opened 22 years ago
Closed 20 years ago
small-caps are drawn in underline colour
Categories
(Core :: Layout: Text and Fonts, defect, P1)
Tracking
()
RESOLVED
FIXED
mozilla1.7alpha
People
(Reporter: ian, Assigned: dbaron)
References
()
Details
(Keywords: testcase, Whiteboard: [patch])
Attachments
(2 files)
340 bytes,
text/html
|
Details | |
1.59 KB,
patch
|
bzbarsky
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
Testcase: http://www.hixie.ch/tests/adhoc/css/fonts/variant/001.xml
If you have font-variant: small-caps set with text-decoration: underline, the
colour of the small caps (not the big caps) is drawn the colour of the
underline, not the colour of the text (like the big caps).
Assignee | ||
Comment 1•22 years ago
|
||
I'm guessing one chunk of code is doing a SetColor on a rendering context and
not undoing it, and another chunk of code is relying on the color not being changed.
Comment 2•22 years ago
|
||
yeah nsTextFrame::RenderString never sets the color on the rendering context
(this is called from PaintTextSlowly) unliks PaintAsciiText, which does set the
color.
Updated•22 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Assignee | ||
Comment 3•22 years ago
|
||
Taking.
Assignee: font → dbaron
Priority: P3 → P1
Whiteboard: [patch]
Target Milestone: Future → mozilla1.4alpha
Comment 4•22 years ago
|
||
OK, this needs a new testcase, since it's now quirks-only, since bug 1777 never
triggers this ickiness.
The issue is that RenderString calls DrawString and DrawTextDecorations in a
loop one after the other. So the calls to SetColor before the call into
RenderString are not enough; the color needs to be set before every DrawString
in RenderString
Comment 5•22 years ago
|
||
Actually, not that simple. Those SetColor() calls _used_ to be there. Then
anthonyd removed them as "redundant" and "breaking selection colors". Too bad
there's no bug number cited and no steps to reproduce.... (see
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&file=nsTextFrame.cpp&rev2=1.247&rev1=1.246)
Assignee | ||
Comment 7•21 years ago
|
||
selection colors look fine to me
Assignee | ||
Updated•21 years ago
|
Attachment #139752 -
Flags: superreview?(bz-vacation)
Attachment #139752 -
Flags: review?(bz-vacation)
Comment 8•21 years ago
|
||
Comment on attachment 139752 [details] [diff] [review]
patch
Yeah, if selection colors are still good, r+sr=bzbarsky.
Attachment #139752 -
Flags: superreview?(bz-vacation)
Attachment #139752 -
Flags: superreview+
Attachment #139752 -
Flags: review?(bz-vacation)
Attachment #139752 -
Flags: review+
Assignee | ||
Updated•21 years ago
|
Target Milestone: mozilla1.4alpha → mozilla1.7alpha
Assignee | ||
Comment 9•21 years ago
|
||
Fix checked in to trunk, 2004-02-03 10:27 -0800.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Comment 10•21 years ago
|
||
Hmm.. In a current build if I select the text "HAS: PASS" in that testcase, the
selection colors are off -- the "HAS:" is green while the "PASS" is white. The
"HAS:" is white up until I select the "P".
Similarly, if I select the "SE" in "PASSED", the "PAS" is painted in white (so
it's white on white).
Reopening; that patch is no good...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 11•21 years ago
|
||
Selection problem mentioned in comment 10 is bug 235101. Adding dependency.
Depends on: 235101
Assignee | ||
Comment 12•20 years ago
|
||
(In reply to comment #11)
> Selection problem mentioned in comment 10 is bug 235101. Adding dependency.
...so this bug is still fixed.
Status: REOPENED → RESOLVED
Closed: 21 years ago → 20 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•