Closed Bug 232116 Opened 21 years ago Closed 2 years ago

"ButtonText" color doesn't take OS theme into account on Windows

Categories

(Core :: Widget: Win32, defect)

x86
Windows XP
defect
Not set
minor

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: mozilla, Unassigned)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7

Using Windows XP with the Blackcomb Pro visual style (see
http://www.themexp.org/view_info.php?id=130), which uses a dark button colour
with a light text colour, Firebird renders the text on buttons in black text,
rather than the grey colour that is displayed by buttons elsewhere in the OS.

Reproducible: Always

Steps to Reproduce:
1. Use Blackcomb Pro visual style on Windows XP
2. Display a page or XUL window containing buttons
3. Observe the button text colour

Actual Results:  
The button text is black

Expected Results:  
Displayed the correct button text colour as per the OS theme
-> arvid
Assignee: blake → arvid
Adding dependancy to bug 223959: [META] Firebird uses hardcoded colors for texts
and backgrounds

See bug 222799 for another Blackcomb-related bug.
Blocks: 223959
Severity: trivial → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
Component: General → OS Integration
QA Contact: os.integration
This probably isn't related to bug 223959, but instead it is a quirk of how themes work. The theme can, IIRC, specify text colours and stuff for widgets, so what's likely happening here is that the system colour for text is black, but the theme's button widget specifies the grey.

Not fun to fix, but it serves Gecko right for faking the entire thing ;)
Assignee: arvid.axelsson → nobody
No longer blocks: 223959
Component: Shell Integration → Theme
QA Contact: shell.integration → theme
Component: Theme → Layout: Form Controls
Product: Firefox → Core
QA Contact: theme → layout.form-controls
I'm going to mark this incomplete (or more precisely "bug filed before we implemented native theming of controls").  If this is still a problem with a current build, please reopen.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → INCOMPLETE
Though if this was really about _XUL_ buttons and not HTML ones, then it was in fact a themes bug.
It's certainly still the case in Firefox 3.6.2 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.2) Gecko/20100316 Firefox/3.6.2), and it is XUL buttons that are at issue here; it also isn't a Firefox: Theme bug - I'd go more with Core: Layout: Text, but the code I wrote 3+ years ago touched:
  mozilla/gfx/public/nsITheme.h
  mozilla/layout/base/nsCSSRendering.h
  mozilla/layout/base/nsCSSRendering.cpp
  mozilla/layout/generic/nsTextFrameThebes.cpp
  mozilla/layout/style/Makefile.in
  mozilla/layout/style/nsComputedDOMStyle.cpp
  mozilla/layout/style/nsCSSKeywordList.h
  mozilla/layout/style/nsCSSProps.cpp
  mozilla/layout/xul/base/src/nsTextBoxFrame.cpp
Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---
> but the code I wrote 3+ years ago touched

Which code?  Relevant to this bug how?

XUL buttons use the following styles (from toolkit/themes/winstripe/global/button.css):

  -moz-appearance: button;
  color: ButtonTest;
  background-color: ThreeDFace;

Is the moz-appearance rendering broken?  Is it not being used?
The code is stuff I wrote in my person tree to fix this bug.

The issue is that -moz-appearance overrides background (and border, padding) but not color. Native themes have a foreground color specified (TMT_TEXTCOLOR) just as much as any of the other properties.

The ideal solution is to actually call DrawThemeText()/DrawThemeTextEx() for rendering the text on a themed control. My patch was simpler, and just did some overriding and inheriting of color from -moz-appearance from GetThemeColor().
> The issue is that -moz-appearance overrides background (and border, padding)
> but not color. 

Ah, ok.

> Native themes have a foreground color specified (TMT_TEXTCOLOR)

Shouldn't "color: ButtonText" pick up that setting?  The fact that it's not sounds like the real bug to me.

The color "ButtonText" corresponds to is gotten via ::GetSysColor(COLOR_BTNTEXT).  I assume that it would need to be smarter than this to work with native themes?

On the other hand, I guess if native theming is dropped we'd want to use whatever GetSysColor returns, since the themed color would not match the button background (ThreeDFace) at that point.

In any case, none of that is a form controls issue.
Component: Layout: Form Controls → Widget: Win32
QA Contact: layout.form-controls → win32
Summary: XUL buttons do not inherit OS theme text colour → "ButtonText" color doesn't take OS theme into account on Windows
The native theme defines the system colors, including COLOR_BTNTEXT, but every item, part and state it defines can have its own foreground color. It isn't unreasonable for it to expect an object like a button, tab, groupbox, etc. to either be drawn entirely natively (DrawThemeText and co.) or entirely by hand (GetSysColor and co.) - we've got a mix currently.

I want to make clear that this is not limited to ButtonText or buttons; any use of GetSysColor in a native-themed component is wrong. There aren't system colors for everything native themes can define, e.g. text color on tabs. The only correct color for a native-themed component is that returned by GetThemeColor(part/state).

You are correct that without a theme, it should use GetSysColor.

We have switched to non-native theming for form controls on all platforms in bug 1535761.

Status: REOPENED → RESOLVED
Closed: 14 years ago2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: