Closed Bug 69436 Opened 19 years ago Closed 18 years ago
system colors still ignored for mail/news reader background
(from the author of http://bugzilla.mozilla.org/show_bug.cgi?id=57429 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 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=23210
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 http://bugzilla.mozilla.org/showattachment.cgi?attach_id=17629 (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
Status: UNCONFIRMED → NEW
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 criteria. 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).
This got fixed as part of bug 74248.
Status: NEW → RESOLVED
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.
Status: RESOLVED → REOPENED
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 www.mozilla.org/docs 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:-)
*** 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)
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WORKSFORME
See comment 21. I think this was "fixed" in a way that caused the opposite problem.
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 ground. 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
You need to log in before you can comment on or make changes to this bug.