19329 - default page background color differs between platforms [mac][gfx]

Status: RESOLVED FIXED

(Core :: XUL, defect, P4)

Description

[Simon Fraser [no longer active]]

On Windows, the default page background color is white (i.e. for an HTML page
that does not specify a background color or image on the BODY tag, or through
CSS). On Mac and UNIX, it's gray. Why the difference?

Comment 1

[Pierre Saslawsky]

I guess it has something to do with widget/nsLookAndFeel.cpp on Mac and Unix:
    case eColor_WindowBackground:
        aColor = NS_RGB(0xdd,0xdd,0xdd);
        break;

Comment 2

[leger]

Setting QA Contact/component

Comment 3

[Peter Trudelle]

reassigning to sdagley as p4 for m13

Comment 4

[Peter Trudelle]

why was this left on M13?  moving to m15

Comment 5

[Sitsofe Wheeler]

*** Bug 26772 has been marked as a duplicate of this bug. ***

Comment 6

[Simon Fraser [no longer active]]

Why does sdagley have this? Reassigning to pierre, since this is really a layout 
issue.

Comment 7

[Marc Attinasi]

Assigning to ekrock: 1/3 of Pierre's NEW bugs to help reduce his doomage factor

Comment 8

[Pierre Saslawsky]

Reassigned back to me these bugs that shouldn't have left my list.

Comment 9

[Marc Attinasi]

On Windows the bkcolor is a system setting, as it is on gtk, qt and OS/2. The 
mac and BeOS implementations of nsLookAndFeel have hard-coded the values instead 
of getting the system values. (I did not look at the other platforms)

This is either OK as is, or the platform implementations of nsLookAndFeel 
that have hard-coded colors need to be updated to reflect system colors. This 
should probably be somebody else's bug...

Comment 10

[Pierre Saslawsky]

sfraser: The CSS2 System Colors are a related yet separate issue. It was assigned 
to sdagley because the platform-specific implementations of nsLookAndFeel belong 
to XPWidgets. Bouncing back to XPWidgets.

Comment 11

[Peter Trudelle]

reassigning to rods, who I'm told has claimed this as his very own.

Comment 12

[rods (gone)]

The nsLookAndFeel on the make needs to get the system color for the background 
of pages just like the other platforms

Comment 13

[Simon Fraser [no longer active]]

On Mac, there is no widely accepted background color for HTML pages in the 
system, which is probably the reason why the platforms differ. However, Internet 
Config has a setting for the page background color, as well as visitied and 
unvisited links, and I think we should start using these.

davidm is in the process of adding Internet Config support, so there will be a 
service you can call to get info from IC.

Comment 14

[dcone (gone)]

This bug has been marked future because we have determined that it is not 
critical for netscape 6.0.  If you feel this is an error, or if it blocks your 
work in some way -- please attach your concern to the bug for reconsideration.

Comment 15

[djoham]

this may seem like a silly suggestion, but why don't we simply modify html.css
from this:

body {
  display: block;
  line-height: normal;
  margin: 8px;
}

to this:

body {
  display: block;
  line-height: normal;
  margin: 8px;
  background-color: white; /* ensures platform parity on background colors */	
}

In the future, we can add more platform specific stuff for a "more correct"
solution. In the here and now, we're consistent across platforms.

There is also a mozilla precident for this. The html.css frame background color
is defined as being white. This solution would simply be doing the same thing
for non-frame pages.

Thoughts?

David

Comment 16

[Hixie (not reading bugmail)]

This bug is not valid. We get the colour of the page background from the system,
and thus fit with the user's preferences by default. You could take three 
Windows systems and we would have a different page background colour on each;
it's not a per-platform thing it is a per-user thing.

If you want the default background changed for a particular platform, file a bug
directly on that platform. Mac and Xlib have a hard coded values, because (I
guess) those platforms do not have user-editable preferences for colours (!).

The proposed solution would not work due to clashing with CSS rules for 
background propagation (this is a complex issue, mail me if you want details).

Also, the "mozilla precedent" was actually a bug causing performance problems,
and you will see the frame background colours have now been set to transparent.
In any case, that white was not being used as 'white' anywhere. (The colour was
overriden by the document that was drawn on the frame itself.)

FWIW, bug 1004 is covering the issue of implementing nsLookAndFeel correctly on 
the Mac.

Comment 17

[Pierre Saslawsky]

Reopening because nobody knows where the gray background is coming from. I asked 
the following question to Don, Buster, Waterson, Kevin and others last month but 
nobidy replied. Ian is persuaded that it comes from the nsPresContext constructor 
but I wrote 3 times already that it does not.
---
In html.css, when the viewport and viewport-scroll have "background-color: 
inherit", we get a gray background on the web pages - rgb(192,192,192) - but it 
doesn't come from nsLookAndFeel, nor StyleColorImpl::ResetFrom(), nor from
nsPresContext::nsPresContext(). Do you know where that default background is
set? 

Comment 18

[Pierre Saslawsky]

I should have added that when viewport and viewport-scroll don't have 
"background-color: inherit" (which isn't what we want) then the color comes from 
the LookAndFeel.

Comment 19

[Andrew Thompson]

Bug 5721 is the general "support Internet Config properly" bug on the Mac.

This can be considered to be a part of that bug, if you like.

Comment 20

[Mike Pinkerton (not reading bugmail)]

boy howdy. this bug has been around the block.

i know for a fact that this difference is causing certain pages to look crappy on 
mac when they look ok on win32. tables end up with a gray bg on mac, and on win32 
they're white and so it looks a-ok.

http://bugzilla.mozilla.org/show_bug.cgi?id=71775

Comment 21

[Kathleen :Brade]

I think the color we give (hardcoded) in the Mac version of nsLookAndFeel.cpp, 
should be white for eColor_WindowBackground.

I made this change (see Pierre's first comment for location) and haven't seen any 
problems in either theme.

Comment 22

[Mike Pinkerton (not reading bugmail)]

brade, since you made the bg white, can you try 

http://www.headphone.com/ProductsHeadphones/SennheiserHD570.asp

and see if the table bg is gray or white? On the tip, it's an ugly gray.

Comment 23

[Kathleen :Brade]

I'll take this bug and do the IC thing

Comment 24

[Kathleen :Brade]

Attachment: get background color from Internet Config

Comment 25

[Henri Sivonen (:hsivonen)]

Does IC default to #FFFFFF? Having a default other than #FFFFFF defeats the purpose of 
the setting because Web authors will keep overriding the user pref on a per page basis if 
the default is unacceptable to them. (Page authors, in general, don't want gray 
backgrounds. Defaulting to gray way back in Mosaic and Nav 1 was a bad idea.)

Comment 26

[Kathleen :Brade]

The default of Internet Config is irrelevant (but yes, it is white).  The reason 
is that if the Preference for using the "OS Settings" is checked, this is what 
the OS has set (whether the user has that setting in IC to orange, red, blue, 
gray, or white).

Henri--I don't understand your point.  If the user sets the preference in the OS, 
we should be following it (not trying to guess what a page author may or may not 
have wanted it to appear with).

Comment 27

[Simon Fraser [no longer active]]

Patch looks good. My only reservation is the overhead of getting the IC service 
each time we request the page background or foreground color. Does anyone have 
opinions on this?

Comment 28

[Kathleen :Brade]

nsInternetConfigService::GetColor gets called 3 times for a new window open and 
once for each URL that is loaded.

Unfortunately I don't have the instrumentation installed right now to determine 
how long it takes to call into IC on my Mac.

If there is a performance problem, I think we should fix the problem of the 
nsPresContext constructor not calling into LookAndFeel when it may not need the 
information anyways (or some other related fix).

Other opinions?

Comment 29

[Kathleen :Brade]

fix checked in