Closed Bug 25349 Opened 25 years ago Closed 24 years ago

sidebar, dialogs using Win32 text colour; bad UI if white

Categories

(SeaMonkey :: General, defect, P3)

x86
Windows 95

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: johnzo, Assigned: bugs)

Details

I typically set Windows to a light-on-dark colour scheme.  The browser appears
to obey the light text setting, however, it seems as though the sidebar and
preference dialog are hardcoded to a white background colour, making the text
impossible to read unless I reset my colours to a more standard dark-on-light
scheme.

I'm using the precompiled M13 of Jan 26th on Windows 95 4.00.950B.

Thanks -- this is a common irk of mine with Windows software.  :)
The big problem here is not that Mozilla is not honouring the system-specified 
background colour with the default skin, but that it *is* honouring the
system-specified foreground text colour, with the default skin, when the
same skin defines its own background colours.

This problem is worst with the sidebar and the left part of the Prefs UI,
but the same problem can be seen on all the XP menus: white on light grey
is not the easiest to read. Menus and widgets are displaying properly;
the problem seems confined to dialogs.

To Reproduce: 
1. Bring up the Display Control Panel, click on the Appearance tab; under
   "Scheme:" choose "High Contrast Black", then [Apply] or [Ok].
2. Launch or switch back to Mozilla.
3. Tour the UI: the sidebar, the Prefs UI, a dialog or two. 

Actual Results:
White text (specified by Windows; the "Item" on the Appearance tab that 
specifies this is called "Window" for some unknown reason") on white or light 
grey appears in the locations specified in step 3.

Expected Results:
Black text (specified by the Mozilla chrome) on white or light grey appears in 
the locations specified in step 3.

A quick tour of global.css shows that color properties are being set for just
about every UI element but window.dialog.

Passing this one directly to german@netscape.com in case fixing this has
ramifications that need to be worked out beforehand.

BTW, There is already a bug open, bug 22620, "[RFE] Available skin matching OS 
System UI colours", M20, enhancement, for making it possible to use the 
system-specified UI colours in a systematic way, so they work together,
instead of the default coordinated Mozilla chrome. This is probably what
you're looking for, johnzo@sff.net.

Changing summary from "sidebar, preferences not obeying win95 background colors"
to "sidebar, dialogs using Win32 text colour; bad result if white"

Tested with: 2000-01-27-08-M14 nightly binary on Windows NT 4.0sp3
Assignee: nobody → german
Component: Browser-General → UE/UI
QA Contact: nobody → elig
Summary: sidebar, preferences not obeying win95 background colors → sidebar, dialogs using Win32 text colour; bad UI if white
Is this a DUP of bug 19554, "[BETA][Skins] Global skin must contain all 
font/color/border info", ASSIGNED, M16?
no this is not a dup of bug 19554, which states that all color, font etc 
information should be centralized in global.css as classes to advertise 
consistent re-use across all apps. To answer the other question, it would be a 
haphardous design to mix system with deliberate colors, the current skin is the 
latter. As you know we will likely also ship a system color skin, for those users 
who prefer that. We haven't commited to a date, but Ben's working on that.
Part of some default skins (like the one from the Netscape) is branding of course 
and thus represents a deliberate choice of color and design.
As for your concrete aspects of the prefs dialog it should not use white as the 
base color, as well as in the current skin it should not use the system font 
colors but instead black. What you are seeing is precisely what we're trying to 
avoid - mixing system with other colors. Re-assigning to Ben, who is doing work 
on prefs as well as a system color skin.
Assignee: german → ben
Target Milestone: M20
our current skin should have all hard coded values, right german?

the system colour bug is a dupe of 22620

*** This bug has been marked as a duplicate of 22620 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
  >our current skin should have all hard coded values, right german?
Should, but doesn't!  Actually following the steps above will demonstrate
that quite clearly; it is still possible to see white text mirroring system
settings on dialogs on grey or white backgrounds set by the default chrome.
The default chrome should be using #000000 for dialogs, and isn't.

Retested with: 2000-02-01-08-M14 nightly binary on Windows NT 4.0 - the
problem remains. The colour scheme used in the example is a worst case, but 
someone who sets their text colour to something like #400040 will see a UI that 
has colours that were just never meant to be together, ruining the look of
the default chrome.

REOPENing; the problem seen in the Actual Results section has nothing to do
with a "system colour" skin, it is a defect with the default skin.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Component: UE/UI → User Interface: Design Feedback
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
this is NOT a problem with the skin at all. the current skin does not use system 
colours. Please verify that you do not have a pref set to use windows colours. 
There was a bug previously that was along the lines of colour settings in prefs 
affecting chrome as well as content. I cannot remember the bug # but this is 
probably a dupe of that. 
No comments added. Marking worksforme. 
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WORKSFORME
Verified
Status: RESOLVED → VERIFIED
Component: User Interface Design → Browser-General
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.