161600 - Tooltip background color ignores system setting

Status: RESOLVED FIXED

(Core :: Widget: Win32, defect)

Description

[Anthony DiSante]

On my computer, I have set the tooltips to be white text on red background.  
But in Mozilla, the background isn't red, it's white.  So my tooltips are 
white text on white background.... i.e., invisible.  I'm using version 
1.1beta, "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.1b) 
Gecko/20020721", on WinXP.

Comment 1

[R.K.Aa.]

Reassign.

Comment 2

[Boris Zbarsky [:bzbarsky]]

regression of bug 66131

Comment 3

[Mats Palmgren (inactive)]

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

Comment 4

[Ian Nartowicz]

Isn't bug #127441 also a duplicate?

Comment 5

[Oleg Sidletskiy]

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

Comment 6

[Oleg Sidletskiy]

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

Comment 7

[Oleg Sidletskiy]

Also see these attachments from my duped bug to easily see the bug:

Windows Classic Style:
http://bugzilla.mozilla.org/attachment.cgi?id=147756&action=view
Windows XP Style:
http://bugzilla.mozilla.org/attachment.cgi?id=147757&action=view

Comment 8

[Jo Hermans]

Mentioned on "Lim Chee Aun's rundown of Firefox UI glitches"
<http://cheeaun.phoenity.com/weblog/archives/2004_08_01_archive.html#post-109326641062302022>

(with a workaround)

Comment 9

[Peter van der Woude [:Peter6]]

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

Comment 10

[Nickolay_Ponomarev]

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

Comment 11

[:Gavin Sharp [email: [e-mail]]]

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

Comment 12

[:Gavin Sharp [email: [e-mail]]]

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

Comment 13

[Ria Klaassen (not reading all bugmail)]

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

Comment 14

[red881988]

This bug was noted 4 years ago!!!
I would have thought that it wouldn't be that hard to fix, but it's still here.  With the number of Windows XP themes which different people use I'm surprised that this hasn't come up more.  But actually it has... looking at the number of different duplicate bug reports have been submitted you would think that someone would have finally gone and done something about this.  If I had the time I"d try and find the bug myself, but I simply don't and wouldn't have a clue where to even start looking in the source code to find this anyway.

Comment 15

[red881988]

Did a little testing and it seems that the problem come from the popup.css file in themes.  The problem is not theme specific however and is instead from how Mozilla handles this section:
tooltip {
  -moz-appearance: tooltip;
  margin-top: 21px;
  border: 1px solid InfoText;
  padding: 2px 3px;
  max-width: 40em;
  background-color: InfoBackground;
  color: InfoText;
  font: message-box;
}

The problem is not the colour but rather -moz-appearance: tooltip. On windows this seems to not work and results in having a background colour of white.  Interestingly though the forecolour is set correctly.  Setting the -mos-appearance to none will allow the tooltip to display the correct colours.  I'm not sure if -moz-appearance: tooltip sets any other properties however and having to edit every theme you want to use is a pain and really shouldn't have to be done.

I can't say whether this is a problem on other platforms as I haven't tested it. I'd say not as there was another 'bug' regarding banana yellow tooltips on OSX (unless they are related).

Also this bug should be reassigned to somebody else.  If [e-mail] hasn't done anything on it for 4 years I doubt they'll do anything now.

Comment 16

[Andrei Todor]

(In reply to comment #15)

First check out all the duplicates... someone has suggested the fix already.
On the last duplicate I wrote what -moz-appearance should have as a value to work right as a summary.

I just updated it in the installation kit and everytime I have to install it it's fixed (unless the theme jar needs an update)!

Comment 17

[red881988]

(In reply to comment #16)

That is not a fix that is a workaround. If it were a fix then user's wouldn't need to change anything. Having to change every theme just to install or update on Windows is just plain stupid and the average user will not know how to do it. Mozilla core itself should be fixed so that -moz-appearance: tooltip; behaves correctly on Windows like on all other platforms.

Comment 18

[Kai Liu]

Attachment: Patch to render tooltips classically

Noting that this bug is present only in Luna (and other "themed" Windows styles) and not in classic Windows, it narrows down the problem to nsNativeThemeWin::DrawWidgetBackground.  *If* the user is using a themed Windows style like Luna or Royale, then it calls DrawThemeBackground in uxtheme.dll (which for some odd reason is not respecting system colors) instead of calling nsNativeThemeWin::ClassicDrawWidgetBackground (which works).

I can't figure out why the call to DrawThemeBackground isn't respecting system colors since this is what Microsoft instructs people to do.  But do we even need to use DrawThemeBackground to draw *tooltips*?  DrawThemeBackground is useful if the themed widgets deviate from the classic style (e.g., themed Royale buttons with gradients vs. the button-face-colored classic buttons).  But tooltips are just simple boxes with a border and thus do not look the same in both a themed style and a classic style.  So we could just use force the use of nsNativeThemeWin::ClassicDrawWidgetBackground when drawing tooltip backgrounds in Windows.

It's a simple one-line patch, which I have attached.  I have tested it this patch, and it works fine.

Comment 19

[Kai Liu]

(In reply to comment #18)
> But tooltips are just simple boxes with a border and thus do not look the same
>

Whoops.  Meant to say they "do look the same".  s/not//;

Comment 21

[Kai Liu]

Attachment: Patch v2

Okay, after some additional testing, this is what I've found:

1) Using UxTheme to render tooltips works fine on Vista.  Vista's tooltips have rounded corners and a gradient background, and Mozilla has always natively rendered them correctly, so this is a bug that applies only to XP.

2) As a test to make sure that there wasn't something wrong with the code on Mozilla's side of things in XP, I tried rendering a tooltip with some other widget theme--e.g., a button theme.  It rendered correctly, so there doesn't seem to be any problems with how Mozilla is calling UxTheme or with the tooltips themselves: it's a problem with how UxTheme decides to draw a tooltip.

3) These two observations suggest that the problem is not with any of Mozilla's code and is instead with UxTheme and that this is also very limited in scope: this problem exists ONLY with XP and ONLY when rendering tooltips.  I think that the problem is that tooltips were never meant to be rendered with UxTheme in XP and that they should always be rendered classic/2K-style in XP.

Anyway, because the UxTheme rendering works fine in Vista, I don't want to break that in the process of fixing this quirk with XP, so I've updated the patch so that it uses a classic rendering only in XP.

And on another note, Mozilla currently uses COLOR_3DDKSHADOW for the tooltip border when doing a classic rendering.  This is incorrect; the correct color to use is COLOR_WINDOWFRAME (this is often not noticed as two colors are often the same or similar).  You can verify this by changing the system's WindowFrame color while leaving all other colors the same; you will notice that throughout the system, tooltip border colors will change along with any changes you make to the WindowFrame color.  So I've taken the liberty of correcting this minor problem in the patch.  :)

I have tested this new patch in both XP and Vista.

Comment 22

[Kai Liu]

Attachment: Patch v3

Oops, forgot to add the WinCE ifndefs.  Sorry.

Comment 23

[Stuart Parmenter]

Comment on attachment 259592 [details] [diff] [review]
Patch v3

seems ok to me

Comment 24

[Nils Maier [:nmaier]]

Attachment: Patch, v4 - Trunk

Patch for trunk, which moved stuff over to widget/ in between.
Based on Kai Liu's patch.
Not sure about Patch v3, is it for trunk too?

Changed:
 * New code location
 * os because mOsVersion, which is a class-variable initialized in c'tor (I doubt that the OS version will change in between ;))
 * Remove that if (brush), as this is fairly pointless.
 * FilLRect brush changed to GetSysColorBrush, which is IIRC prefered over that cast-to-HBRUSH approach.

Comment 25

[Nils Maier [:nmaier]]

Now that it got review again, would somebody mind checking this in?

Comment 26

[Kenneth Herron]

Patch v3 is obsolete? And patch v4 needs superreview before it can be checked in, doesn't it?

Comment 27

[Phil Ringnalda (:philor)]

Comment on attachment 266133 [details] [diff] [review]
Patch, v4 - Trunk

Yeah, despite the way Vlad and Stuart check in to it based on each other's r-only (which for both could just as easily be r+sr), I think by now every single person who looks for [checkin needed] has looked at this and said "Huh. I don't see any reason why I should feel able to check that in without SR."

Comment 28

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 266133 [details] [diff] [review]
Patch, v4 - Trunk

Vlad and Stuart are primarily checking into gfx where sr is not used. This is widget where sr is used...

Comment 29

[Phil Ringnalda (:philor)]

widget/src/windows/nsNativeThemeWin.cpp 3.84
widget/src/windows/nsNativeThemeWin.h 3.26