Classic theme should respond to change of Windows system colors immediately

RESOLVED FIXED in Future

Status

defect
--
minor
RESOLVED FIXED
19 years ago
11 years ago

People

(Reporter: brista, Assigned: kmcclusk)

Tracking

({classic, qawanted})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPLICATE?)

Reporter

Description

19 years ago
Mozilla Build: MTrunk 2001020204
I have noticed that when you change the colors of the windows themselves, in
Windows Display Properties or Desktop Themes, (when using Classic Skin since it
is System Colors supporting) Mozilla has to be restarted for the colors to
change in the classic skin if it is running. Shouldn't this be dyanmic, and
change on the fly without a restart. Thanks guys.
--> XP Toolkit/Widgets, like bug 57799 -- though perhaps this really belongs in 
the Style System component.

Need someone on Windows to confirm this.
Component: User Interface: Design Feedback → XP Toolkit/Widgets
Keywords: classic, qawanted
Summary: When changing the colors of the windows in Windows Display Properties... → Should respond to change of Windows colors immediately

Comment 2

19 years ago
bah, i'm not changing my color scheme just to see we don't handle it.
Assignee: hangas → hewitt
Component: XP Toolkit/Widgets → Skinability

Comment 3

19 years ago
I can confirm this, I've noticed it for a long time.  Strangely, we do actually
update dynamically when system font settings are changed on windows, but not for
colors.  

I have run tests which show that, although no chrome is not updated, Mozilla
still retrieves the new system colors for use within content in the browser. 
Try looking at a page with a system color, then change your colors, then refresh
the page and you'll see that it works.

This isn't a Themes bug, it should probably go over to Style System. We need to
listen for system notification when these colors change, refresh the literal
color values, and then re-paint all windows.
Assignee: hewitt → pierre
Component: Skinability → Style System
QA Contact: mpt → ian
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPLICATE?

Comment 4

19 years ago
Similar to bug 6061 which is set to Browser/Compositor. For this bug we should  
listen and respond to WM_SYSCOLORCHANGE.

The code attached to bug 57799 (#24197) fixes this problem, but on that bug it 
will only compile it for Macintosh.

Some other Windows messages that might be needed to listen to:
(I only tested WM_SYSCOLORCHANGE that will fix this bug, following messages are 
from a random MSDN search)
WM_PALETTECHANGED - This message enables a window that uses a color palette but 
does not have the keyboard focus to realize its logical palette and update its 
client area. 
WM_SETTINGCHANGE - message to all top-level windows when the 
SystemParametersInfo function changes a system-wide setting. The system sends 
this message only if the SystemParametersInfo caller specifies the 
SPIF_SENDCHANGE flag. 
WM_FONTCHANGE - An application sends the WM_FONTCHANGE message to all top-level 
windows in the system after changing the pool of font resources. 
Depends on: 6061

Comment 5

18 years ago
Reassigned to Compositor like bug 6061
Assignee: pierre → kmcclusk
Component: Style System → Compositor
QA Contact: ian → petersen

Comment 6

18 years ago
*** Bug 77526 has been marked as a duplicate of this bug. ***
Assignee

Updated

18 years ago
Target Milestone: --- → Future

Comment 7

18 years ago
I see this aswell with Win98 and build 2001062004
(dunno if its atall relevant but I have the -server option running, which stays
running whilst I close Mozilla and re-start to pick up changed colours)

Comment 8

18 years ago
In build 2001100203 the WM_FONTCHANGE message on Windows does not seem to be 
handled correctly. We can see that the message is received and that 
EnumFontFamilies is called, but new fonts are not used in neither the chrome 
nor in the HTML document.

There seems to be code to handle font changes on Windows
(/widget/src/windows/nsWindow.cpp, line 3027), but something is broken.

It is important for this to work not only for changing UI schemes on Windows, 
but also for supporting plugins (e.g. FAIRY, http://www.borware.com/apps/FAIRY) 
that dynamically install fonts.
*** Bug 117700 has been marked as a duplicate of this bug. ***
*** Bug 70285 has been marked as a duplicate of this bug. ***
This is probably blocked by the fact that the CSS2 doesn't update it yet. 
Adding dependency and updating summary to help searchability.
Depends on: 17978
Summary: Should respond to change of Windows colors immediately → Classic theme should respond to change of Windows system colors immediately

Comment 12

18 years ago
*** Bug 135134 has been marked as a duplicate of this bug. ***
NOTE: I've restarted Windows and Moz still keeps the old system colors, instead
of replacing them with the right ones. The theme I've tested it is the "classic"
one.
The cascading menus shows the right color, while the "main program surface"
don't (sorry I don't know how to call it!) :-).
Assignee

Comment 14

17 years ago
this bug was fixed by the patch for bug 6061
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Assignee

Comment 15

17 years ago
Although the fix for bug 6061 helped, this bug was actually fixed by the patch
for bug 143174
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.