Closed Bug 69436 Opened 19 years ago Closed 18 years ago

system colors still ignored for mail/news reader background


(SeaMonkey :: MailNews: Message Display, defect)

Windows NT
Not set


(Not tracked)



(Reporter: rmp, Assigned: sspitzer)



(Keywords: polish)


(2 files)

(from the author of now marked
fixed, where this was mentioned in the original description.
 Mr. Hewitt acknowledges reports of "some color weirdness" but requests
 "Please file separate bugs specific to those issues" and if he'd
 rather track those bugs on a more specific basis, that's fine by me.)

I'm running Mozilla 0.8 now, which I presume incorporate Mr. Hewitt's
fixes for paying attention to MS Windows & Linux system colors, etc.
And, indeed, menus and dialog boxes do look much better in this
respect.  However, the news reader still has a hardwired light background.
Since my preferences specify a dark background and light foreground, this
makes news pretty hard to read.  I recognize there may be some implications
for printing, but I can uncheck "Use System Colors" when this is a problem.

I have the same workaround that I mentioned in 57429, namely
Reporter still a problem in the latest nightlies?
Still there with Build ID: 2001040304 (see attached .GIF - sorry 'bout
the striations, they're an artifact of the .GIF converter I have at
hand, Microsoft Photo Editor)

Plenty easy to reproduce - just load up the color prefs in
(attached to the original bug report).

Also easy to work around (see the diffs referenced earlier in this
bug report).

But still broken
Assignee: asa → sspitzer
Component: Browser-General → Mail Window Front End
Ever confirmed: true
Product: Browser → MailNews
QA Contact: doronr → esther
setting bug status to New and sending to the appropriate Product.
Since the same problem appears on mail reader (and this is the same component), 
could you please modify the summary to "system colors still ignored for 
mail/news reader background" ? After reading this discussion, I have the 
impression that Mail window is considered it hasn't any background problems.
Summary: system colors still ignored for news reader background → system colors still ignored for mail/news reader background
I wonder if bug 40546 could be related.  (I haven't looked into it at all-- I'm
just guessing.)
*** Bug 92872 has been marked as a duplicate of this bug. ***
just picked up Mozilla 0.9.5 to get some other bugfixes and noticed this
is as it always was.  Since I prefer to run with a classic skin and dark
background, every time I run a new Mozilla, I merge my local copy of
check-check.gif and check-radio.gif into themes\classic.jar.  I also
tweak a few of the stylesheets (disabling some of the bolds in the
mail&news interface 'cause they crowd things if you've selected Large
Fonts in the display properties on MS Windows).

In doing my recursive diff of the exploded classic.jars from 0.9.4 and 0.9.5,
I noticed that skin\classic\messenger\messageBody.css still had
background-color: white;.  I changed it to background-color: window;, as I
usually do, but it triggered a memory - didn't I file a bug report on this
eons ago?
So, just in case anybody else is still following this bug, yup, I'm still
seeing it, too.
Could you attach a current diff -u of the patch, if it's something suitable for
being checked in?  (It was never clear to me that there was a patch at all -- it
was only mentioned in the initial comment.)
> Could you attach a current diff -u of the patch, if it's something
> suitable for being checked in?  (It was never clear to me that there
> was a patch at all -- it was only mentioned in the initial comment.)

     Yeah, sorry 'bout that.  This bug report came about as a breakup
of an earlier, more inclusive report.  I shoulda done a little more
to re-establish context.  The patch (in various similar forms - style
sheets are rapidly moving targets) has worked for me.  Whether it's
suitable for being checked in, I dunno, I'm not well versed in the

     The fact that it's been left the way it is for so long does make
me wonder it has been preserved because of, say, a poor interaction
between printing and not having a white background.  For myself, I
have a macro that lets me toggle Use system colors with just two
keystrokes (Mozilla seems to be much more literal about printing
using the colors on the screen than Netscapes 4.x were) and I often
use that before printing (and then revert afterwards).
Keywords: patch, polish, review, ui
This got fixed as part of bug 74248.
Closed: 18 years ago
Resolution: --- → FIXED
Does the relevant style rule actually work?  (Did you test?  I didn't...)  See
the diffs I had to messageBody.css in attachment 62713 [details] [diff] [review] on bug 91662 (admittedly
unrelated to that bug).
Also, does the change in the patch above (and what was checked in) cause
problems when there are dark system colors and "Use System Colors" is *disabled*?
Setting mozilla prefs to white text on a black background worksforme in news
reader (I get white text on a black background).  I should have mentioned that,
I guess....

Why would this cause problems with disabled system colors?
It forces the background to a system color even when the system color prefs are
disabled, and the foreground color would be whatever's in the prefs.
Ah.  And in browser we don't use system colors for background, so we never run
into this problem.... right...

I should note that I have "Use system colors" disabled and it used my background
for prefs, but I have no GTK theme in effect so there is basically no system
"window" color here at the moment.  Do we just use prefs as a fallback in that case?

Reopening this till we can decide what we really want to do here.  To clarify,
the change in question was accidentally checked in with the fix for bug 74248.
Resolution: FIXED → ---
Looks to me like you changed a lot of stuff that isn't related to this bug. Can
you attach a cleaner patch with only the relevant changes?
Håkan, what are you talking about?  :)
Comment on attachment 53663 [details] [diff] [review]
diffs to make message body background use system colors instead of white

I must've accidently been looking at some other patch will having this bug open
- d'oh!

This patch looks fine.	r=hwaara

I suggest you ask hewitt for super-review, since this a themes change.
Attachment #53663 - Flags: review+
A patch like that was already checked in as part of a different bug, but my
comments above say that:
 1) it probably doesn't do anything, and
 2) if it did, it would fix one case and break the opposite.
(original bug reporter again)

This is not an update as such, but. . .

Is there a document in Mozilla-land that explains how themes, color preferences
and printing interact in the browser and in the mail/news reader?  (I know style
sheets come into this, too, but I presume I can find all the docs on that I
need.)  I skimmed theme-related stuff under and didn't find
anything obvious (although I might easily have skimmed past it).

Seems like such an explanation would be of assistance to those following this bug
(and the lack of such an explanation might partly explain the continued existence
of this bug:-)
No longer blocks: 123569
*** Bug 112591 has been marked as a duplicate of this bug. ***
Is seems to work in 0.9.8 on Linux. 
When I check system colors, both text and background of news match classic skin
colors, when I uncheck system colors, both change to whatever I have selected in
colors dialog.
But this version of Mozilla might have been patched by Mandrake.
(this is the original reporter)

works for me in 0.9.9 2002031104 (that is, I didn't have to edit
any .css to get the system background in the mail/news reader when
installing a new milestone)
Closed: 18 years ago18 years ago
Resolution: --- → WORKSFORME
See comment 21.  I think this was "fixed" in a way that caused the opposite
OK, never mind.  I get it.  The rule I mentioned there should be removed, since
it won't have any effect until bug 130728 is fixed.
The background color of the message pane should be white by default, no matter
if "Use system colors" is enabled or not. The white rule is there to make sure
that we don't use the browser background color, which is grey by default (this
looks very ugly IMO and practically all websites override it, usually to white).
(I think that Windows system colors also spepcify white by default for window
content backgrounds, so we should be fine in the "Use system colors" case.)
If a patch achieves the same, fine with me.
The default browser background color has been white for ages.  Since we use the
default browser color, we should also use the default browser background color.
 And currently, we do.
well, there's default and there's default

MS Windows OSses ship with a white background by default, but they also
ship with color schemes in the display control panel that have a black

And when you select one of these, you'll get a black background in most
of your windows.  Except Mozilla's mail reader, in 0.9.8 and earlier.

And when you selected that dark background color scheme, it picked a light
foreground for you.  Which could be invisible (or very hard to see) against
your white mail reader background in Mozilla 0.9.8 and earlier.

Which is why I was editing my .css in 0.9.8 and earlier.

0.9.9 fixes this, I think.
I agree with #29 and #30. There must be consistency or things break in some setups.
However, I can see a small glitch in my browser still. Headers of mail messages
included as part of multipart MIME messages have still gray background. Or I
beleive it's this, I'll check once such message arrives again.
But my mozilla might be outdated by now.
> well, there's default and there's default

The default is: Install Windows, change nothing. Install Mozilla, change nothing
(except maybe "Use System colors).

> Headers of mail messages
> included as part of multipart MIME messages have still gray background.

That's intended. The foreground should not follow the Windows window foreground
color pref then, though. Not sure, if it does. It's a different bug in any case.
OK posted as Bug 131122
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.