Closed
Bug 46956
Opened 25 years ago
Closed 24 years ago
[modern] inconsistent text colors
Categories
(SeaMonkey :: Themes, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: fantasai.bugs, Assigned: hewitt)
Details
(Keywords: modern, Whiteboard: nsbeta3-)
Overview:
I switched my system colors to pale blue 3D objects with teal text.
I also changed the window background to pale beige. The window text was
teal, due to a bug in Windows 2000 forcing changes to the message text
and window text colors together. I also changed the button text color to
magenta.
In Mozilla, I selected the modern skin, which does not inherit the pale
blue for the 3D objects (buttons & dialogs and such). That's fine,
since it isn't supposed to. But the text varied between teal and black
from button to button and dialog to dialog.
Actual Results:
It was teal:
- in the preferences hierarchy list
- on the preferences OK and Cancel buttons
- in the status bar
- on the search button
- in the bookmarks manager window
- in every dialog I opened, except those mentioned above
- *on* the composer heading level pop up menu (on the toolbar)
It was black:
- *in* the composer heading level pop up menu (on the toolbar)
- in the preferences text & panel-specific buttons
- in the toolbars
Expected Results:
Because the Modern skin does not honor system colors, /nothing/ should
have been teal. What if I'd chosen gray as my window/3D object text? I
wouldn't be able to read a thing. (Also, buttons shouldn't be inheriting
the message text color anyway.)
Tested on Mozilla nightly build (id: 2000072810) on Windows 2000
Comment 1•25 years ago
|
||
Fantasi: the Skinability component is for problems with skin switching. The
Themes component is for issues with specific themes. Thanks.
Assignee: ben → hangas
Component: Skinability → Themes
QA Contact: BlakeR1234 → paw
This one looks like a skinability bug. Since the modern skin does not (to my
knowledge) attempt to modify the font color, the color should not be changing at
all. So if it is changing then this would be a skinability/layout bug. Sending
to skinability to see if they can help narrow this down.
Assignee: hangas → ben
Component: Themes → Skinability
QA Contact: paw → BlakeR1234
Comment 3•25 years ago
|
||
confirming using the 2000081108 nightly on win2k. I did the exact same steps
fantasai@escape.com did & i got the actual results as the reporter said
Status: UNCONFIRMED → NEW
Ever confirmed: true
> Since the modern skin does not (to my knowledge) attempt to modify the font
> color, the color should not be changing at all.
The default colors, if none are specified, should be the system colors, and
that's what they are. This is not a skinnability problem; it's a mistake in the
modern chrome.
Here's the fix:
--in global.css--
window
{
+ color : #000000;
background-color : #FFFFFF;
padding : 0px;
font-family : Geneva, Tahoma, Helvetica, Arial, sans-serif;
}
Sending back to Themes component, reassigning, and updating QA contact.
Assignee: ben → hangas
Component: Skinability → Themes
QA Contact: BlakeR1234 → pmac
Giving nsbeta3+, looks like another great contribution. Thanks. Sending to Joe.
Marking nsbeta3- because this was not a P1 or P2 bug.
Whiteboard: nsbeta3+ → nsbeta3-
Please re-evaluate.
This has a fix in hand and the risk is so low as to be almost non-existant.
If you absolutely must have a CVS patch, tell me, and I'll learn to write one.
BTW, this fix removes some symptoms of bug 22963, which was also marked nsbeta3+
Comment 8•24 years ago
|
||
Adding myself to cc
Assignee | ||
Comment 9•24 years ago
|
||
Fixed.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•