431306 - :-moz-system-metric() isn't live / should be updated when changing the OS theme

Status: VERIFIED DUPLICATE of bug 447045

(Core :: CSS Parsing and Computation, enhancement)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008042806 Minefield/3.0pre ID:2008042806

Depending on the selected OS theme Firefox choose its own theme. I tested it on Win XP and noticed that you have to restart the browser to take the changes in effect. I believe that there is a notification which will be sent by the system to inform running applications about the theme change. That could allow Firefox to immediately change its theme without a restart.

I've filed that bug under Windows because I don't know how it is handled on Linux. OS X only uses one theme, correct?

Comment 1

[Nochum Sossonko [:Natch]]

I don't quite understand...

If you go to the addons manager and enable a theme not presently in use, you have to restart the browser for it to take affect, (just like if you enable/disable any other addon) why do you expect it to change the theme without a restart?

If your intention was that changing any theme in firefox shouldn't require a restart I think you should change the summary.

Comment 2

[Kai Liu]

Well, if you change your Windows appearance from Luna Blue to Luna Olive, the color of the buttons, etc. in Firefox changes along, without a restart.  If you change your Windows appearance from Classic to Luna Olive, your toolbars will change from a flat gray to something green with shadowy gradients, without a restart, and your buttons, which used to have sharp 90 degree angles will have the slightly rounded corners of Luna.

But not all things change along: for example, anything styled differently with the "windows-default-theme" metric.  Or the menus, if the theme change involves toggling the mFlatMenus flag (basically, when crossing the boundary between Classic and non-Classic).

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #2)
> But not all things change along: for example, anything styled differently with
> the "windows-default-theme" metric.  Or the menus, if the theme change involves
> toggling the mFlatMenus flag (basically, when crossing the boundary between
> Classic and non-Classic).

Or e.g. the locations bar left side. Switching from Luna to Classic or back doesn't exchange the rounded with square corners and vice versa. 

Comment 4

[(no longer active)]

(In reply to comment #3)
> Or e.g. the locations bar left side. Switching from Luna to Classic or back
> doesn't exchange the rounded with square corners and vice versa. 

Yes, because the square/non-square differentiation has been implemented using the windows-default-theme metric.

Comment 5

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

Is there a way to make windows-default-theme update itself dynamically?

Comment 6

[(no longer active)]

I would write the patch, but I'm not sure how the change notification for these stuff works.  CCing roc and dbaron to see if they can give me some idea to get started...

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

nsPresContext::ThemeChangedInternal needs to get nsCSSRuleProcessor to rerun InitSystemMetrics (in the part conditional on sThemeChanged, I think, since it's operating on statics and thus should only happen once) and then (not conditional on sThemeChanged) tell its mStyleSet to call ClearRuleCascades on its rule processors (which might require exposing something we don't expose now).  Or something like that... it's possible I'm missing something else that's cached, and that's only after thinking about it for 5 minutes.