Steps to Reproduce: 1.) Set a html tag or a XUL style to use any of the system colors from CSS2. Example: body { background-color: background; } 2.) View in Mozilla 3.) Change system colors Actual Result: The webpage/xul keep previous colors. Expected Result: When the system colors change it should force Mozilla to repaint everything which uses these CSS2 colors (xul, html) Build Date & Platform: 1999-11-01-09-M11 build for Win95 (checked Apprunner)

See also bug 1137 about text selection color

Pushing my M15 bugs to M16

I guess it's a GFX or maybe a Widget problem on Windows. On Mac when you change something in the Appearance control panel, the OS causes an update in all the windows. Reassigned to hyatt.

Need ot listen to sysinfo changed message on windows and update the look and feel object and invalidate all windows.

I don't think invalidating all the window is enough. It seems to Kevin and myself that we may need to re-resolve style. Pierre, what do you think?

Correct: the color is stored as an identifier (eg. eCSSKeyword_appworkspace) in the CSSDeclaration but it gets converted to an RGB value when we map it into the style context. To re-resolve style, you may have to do the same thing as nsPresContext::PreferenceChanged().

It would be nice to have a XP mechanism to re-resolve style on all the windows. It will be triggered by the "sysinfo changed" message on Windows and the Appearance Manager Apple Events on the Mac. When you are done on Windows, please reassign to pinkerton and pavlov. Also, IMHO if it's not trivial, feel free to postpone the bug.

Moving out by executive order.

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

moving to M18

This bug is marked "future" because it is not critical for RTM (Release To Manufacturing). If anyone believes it is critical, please explain why in this bug.

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

Tested on Win95 with 10_02_09_mn6 build. Created a testcase (attached) using background-color: background on BODY element as indicated in 'Steps to Reproduce'. Viewed in Netscape6, then changed system colors adn reloaded. Background color was updated. WORKSFORME.

Making P3 for the next release

Netscape's standard compliance QA team reorganised itself once again, so taking remaining non-tables style bugs. Sorry about the spam. I tried to get this done directly at the database level, but apparently that is "not easy because of the shadow db", "plus it screws up the audit trail", so no can do...

I'm not sure if this is the same problem but Mozilla using the Classic theme doesn't recolor when system colors change under Windows. New windows appear in new colors but parts of old windows don't change the colors at all. Tested with 0.8. Menu colors (eg File menu) are even remembered per window (I expect only one file menu should exist in the whole app, that's probably where all the memory is eaten). To reproduce: 1)run Mozilla under windows and select the classic skin. 2) pull down the file menu 3) change the system colors (of 3d objects) 4) resize the browser window and open new browser window 5) pull down the file menus and edit menus in both windows [6) change the system colors to somethig else again 7) resize the second window and open new browser 8) pull down file, edit and view menus in all three windows] Result: Enjoying a colorful Mozilla Expected: All controls should appear in the new colors.

I'm not sure if this is the same problem but Mozilla using the Classic theme doesn't recolor when system colors change under Windows. New windows appear in new colors but parts of old windows don't change the colors at all. Tested with 0.8. Menu colors (eg File menu) are even remembered per window (I expect only one file menu should exist in the whole app, that's probably where all the memory is eaten). To reproduce: 1)run Mozilla under windows and select the classic skin. 2) pull down the file menu 3) change the system colors (of 3d objects) 4) resize the browser window and open new browser window 5) pull down the file menus and edit menus in both windows [6) change the system colors to somethig else again 7) resize the second window and open new browser 8) pull down file, edit and view menus in all three windows] Result: Enjoying a colorful Mozilla Expected: All controls should appear in the new colors.

Experienced similar problem on Linux: when the GTK theme is canged using the gnomecc configuration tool, all native GTK apps redraw themselves using the new settings but mozilla has to be restarted. I tested with 0.8 I think.

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

i'm bouncing this randomly. there are three possible reasons this isn't working (and i'm in a hurry, i'll shoot now and check later). A. System Colors Change 1. widget/gfx don't get a message from the system 2. widget/gfx get the message and don't send it anywhere B. Colors in edit>preferences>appearance>colors change Accused problem based on B: presshell or whatever aren't registered to be informed about color changes

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061206 Minefield/3.0a1

This is WFM on Windows XP SR-2 using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a6pre) Gecko/20070622 ID:2007062204 -> WORKSFORME

Fixed on Windows by bug 143174. Should be tested on other platforms, but probably covered by theme change notifications on GTK. Somebody should check Mac, though.

Actually, I think it doesn't work on GTK; native theme elements get changed, but not system colors (which are presumably cached somewhere). We may want to split this into separate bugs per-platform, though.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information