This is a follow up bug to bug 543910, specifically https://bugzilla.mozilla.org/show_bug.cgi?id=543910#c41 There are a few different cases in the new Firefox Windows Vista/7 theme where we would like to use the Aero Glass color if we had access to it. One example is styling progress bars differently.

There's some interesting background information in this article, that seems to say this may not be so straightforward: http://www.withinwindows.com/2010/07/01/retrieving-aero-glass-base-color-for-opaque-surface-rendering/

I'm not sure what our policy on using undocumented APIs is. Reading things out of the registry is undeniably Evil but has a better fallback in case Microsoft changes their API (they probably won't if we ship it but we have no guarantee and it's kinda mean on our part). To be safe, we could restrict our usage of this to platforms where we know it works but then we'd have some ugliness on Windows 8 when it comes out (or we backport support as we did for Windows 7 when detecting the default theme).

(In reply to comment #1) That link is interesting; using the customised OS glass colour sounds like a good thing to me. I do have one (a little naive) question on an extra step that will be required to make this work in Vista, as I didn't see it mentioned in the parent bug. If, I assume, DwmGetColorizationColor returns the glass colour of 'light blue', or whichever, and the UI CSS is adjusted/preconfigured to different values then Vista's default method of blacking the titlebar on maximised windows creates a need for an extra style that would change between maximised and windowed. For example, if I use .tabbrowser-tabs > tab:not([selected="true"]) .tab-text { color:white !important; } in my userchrome.css to make background tabs more readable when maximized then making FF windowed makes them quite unreadable on anything but a dark desktop background.

In the case of text, shouldn't Firefox be using the "WindowText" color on areas that will have glass behind them, as in the case of the menu bar and inactive tabs (on top)? And shouldn't the text-shadow use the Glass color or the "Background" color?

I'll take a stab at this but I'd like to have a patch that wants to use it so that I can see if the standard API call is good enough.

Ok, here's the stab. This just uses the official documented API to grab the color. At least for opaque glass, the color we get is not the same as the one used for the glass. Transparent glass is also probably not the desired color. If someone else can point me at a patch that wants to use the color (ex: tab progress bars?), I'd be more than happy to take some screenshots and post them. We can query whether or not the user has opaque glass set. Is this information valuable? Do you want this to be a media query? Also, some curious behavior. We are supposed to get a notification when the glass color changes however if you are just playing around in the control panel, that message is not sent until you actually press the "Save changes" or "OK" button. However, if you call the API during this time (ex: at startup), you'll get the live color value. Sample testcase: data:text/html,<div style="background-color: -moz-win-glass-color; height:100%;">Hey</div>

What would the color look like on platforms without support for Aero-glass?

It falls back to the window color I believe but really a theme should not use it when there's no glass available. This can be done via the -moz-windows-compositor media query.

Stephen tells me this would be nice to have, but doesn't block.

Comment on attachment 466919 [details] [diff] [review] Bug 578780 - Add -moz-win-glass-color keyword and implement using documented API v1.0 >Ok, here's the stab. This just uses the official documented API to grab the >color. At least for opaque glass, the color we get is not the same as the one >used for the glass. Transparent glass is also probably not the desired color. so, not exactly what we want, but ui-r+ in that having access to this color might at least be useful in our design work.

Comment on attachment 466919 [details] [diff] [review] Bug 578780 - Add -moz-win-glass-color keyword and implement using documented API v1.0 Talked about this with Rob a while back on IRC but forgot to add feedback here. This would be good to have so we could still pickup some Glass attributes but not fall victim to poorly anti-aliased text. Example being the formerly translucent background tabs. The color returned here isn't accurate enough however.

We're going to want this for Windows 8's colorful new aero basic theme.

(In reply to Jim Mathies [:jimm] from comment #12) > We're going to want this for Windows 8's colorful new aero basic theme. Actually, in testing on the new aero basic theme, the color returned by DwmGetColorizationColor seems pretty worthless. It certainly doesn't match the underlying color of the window frame the user selects.

(In reply to Jim Mathies [:jimm] from comment #13) > (In reply to Jim Mathies [:jimm] from comment #12) > > We're going to want this for Windows 8's colorful new aero basic theme. > > Actually, in testing on the new aero basic theme, the color returned by > DwmGetColorizationColor seems pretty worthless. It certainly doesn't match > the underlying color of the window frame the user selects. I wonder if they're really finished with the Classic window decorations. They feel unfinished to me. Then again, this is the Beta/Consumer Preview and traditionally they haven't made large changes after that.

(In reply to Jim Mathies [:jimm] from comment #13) > (In reply to Jim Mathies [:jimm] from comment #12) > > We're going to want this for Windows 8's colorful new aero basic theme. > > Actually, in testing on the new aero basic theme, the color returned by > DwmGetColorizationColor seems pretty worthless. It certainly doesn't match > the underlying color of the window frame the user selects. The last approach rob tried returned a color with the right hue but completely wrong brightness and saturation in most cases.

(In reply to Stephen Horlander from comment #15) > (In reply to Jim Mathies [:jimm] from comment #13) > > (In reply to Jim Mathies [:jimm] from comment #12) > > > We're going to want this for Windows 8's colorful new aero basic theme. > > > > Actually, in testing on the new aero basic theme, the color returned by > > DwmGetColorizationColor seems pretty worthless. It certainly doesn't match > > the underlying color of the window frame the user selects. > > The last approach rob tried returned a color with the right hue but > completely wrong brightness and saturation in most cases. In the new aero basic, you can chose a completely opaque color for the window frame just like you would for glass (using the same interface), which translates into color variations for command buttons and other ux elements. I was hoping to get that color from the call but it doesn't return it. There's a registry hack and and a hidden api people have found, I think if the registry hack is reliable we might use that. The other odd thing is - IE manages to change its tab color based on the color selection you make, but we (fx) don't get notification until the user hits save settings. So I wonder how IE is managing to update its tab color in real time.

Seems like we need to have the right contacts at Microsoft to ask them these things. IE should not have access to APIs that we don't. I'm sure they're keen on that given the decade of legal requirements to ensure it and their desire to not end up in court again.

for reference

(In reply to Asa Dotzler [:asa] from comment #17) > Seems like we need to have the right contacts at Microsoft to ask them these > things. IE should not have access to APIs that we don't. I'm sure they're > keen on that given the decade of legal requirements to ensure it and their > desire to not end up in court again. Let's do some due diligence first. There may be new apis we haven't found in the docs yet.

(In reply to Jim Mathies [:jimm] from comment #16) > The other odd thing is - IE manages to change its tab color based on the > color selection you make, but we (fx) don't get notification until the user > hits save settings. So I wonder how IE is managing to update its tab color > in real time. IE's tabs are always translucent AFIAK. I think that is just the window color bleeding through. We had something similar at one point but it breaks sub-pixel anti-aliasing for hardware accelerated text.

For tracking -> Win 8

(In reply to Jim Mathies [:jimm] from comment #16) > The other odd thing is - IE manages to change its tab color based on the > color selection you make, but we (fx) don't get notification until the user > hits save settings. So I wonder how IE is managing to update its tab color > in real time. We should be. I fired up Spy++, and both IE and Firefox receive WM_DWMCOLORIZATIONCOLORCHANGED while moving the slider (without having to click "Save changes"). And the value in wParam changes according to slider changes. Same as the value given by DwmGetColorizationColor (tested via a simple Win32 executable, under VC11). Tested under both Aero and Aero Basic on Windows 8 Consumer Preview (on real hardware). No idea what's up with the colors though. At least under Aero Basic, the hue is right, but saturation and lightness are different. And under Aero Basic, the value returned has an alpha component, even though all uses are opaque colors.

(In reply to Blair McBride (:Unfocused) from comment #22) > (In reply to Jim Mathies [:jimm] from comment #16) > > The other odd thing is - IE manages to change its tab color based on the > > color selection you make, but we (fx) don't get notification until the user > > hits save settings. So I wonder how IE is managing to update its tab color > > in real time. > > We should be. I fired up Spy++, and both IE and Firefox receive > WM_DWMCOLORIZATIONCOLORCHANGED while moving the slider (without having to > click "Save changes"). And the value in wParam changes according to slider > changes. Same as the value given by DwmGetColorizationColor (tested via a > simple Win32 executable, under VC11). I hadn't actually tested this on win8, this is excellent news.

(In reply to Jim Mathies [:jimm] from comment #23) > (In reply to Blair McBride (:Unfocused) from comment #22) > > (In reply to Jim Mathies [:jimm] from comment #16) > > > The other odd thing is - IE manages to change its tab color based on the > > > color selection you make, but we (fx) don't get notification until the user > > > hits save settings. So I wonder how IE is managing to update its tab color > > > in real time. > > > > We should be. I fired up Spy++, and both IE and Firefox receive > > WM_DWMCOLORIZATIONCOLORCHANGED while moving the slider (without having to > > click "Save changes"). And the value in wParam changes according to slider > > changes. Same as the value given by DwmGetColorizationColor (tested via a > > simple Win32 executable, under VC11). > > I hadn't actually tested this on win8, this is excellent news. So for bug 940393, we need something like this. At the moment it's unlikely we'll be able to fix that for the initial version of Australis, as without an API we can't really do anything about it.

Lightness was one of the factors off and lightness is the primary problem with text visibility. If there was a way to test the lightness of the color somehow, like is done for Personas, that's all that's really needed to choose between white text or black text. On the other hand it looks like the information available now is enough to at least provide an accurate *hue* color which could be at 50% brightness and 50% saturation and used to partially match the Glass color... although failure would be really high on anyone with a Black or White aero color (which could in actuality be any hue).

We've punted on bug 940395 and bug 940393 for now, so punting this as well.

Either I've cracked this, or I've cracked. Going back to the original website, I think it actually has all of the information you need. The example values shown in ARGB are: #6B74B8FC with transparency disabled #140C131A with transparency enabled As noted above, the HUE can be calculated from that, both of them are 210`. If we throw out the Alpha channel, and convert them to CMYK we end up with this:: #74B8FC -> CMYK(138, 69, 0, 3) #0C131A -> CMYK(138, 69, 0, 230) Now, I don't have all of the data here, but I'm going to make an assumption. And that assumption is that for whatever crazy reason Microsoft is not using the black point in CMYK the way we would assume they are... and instead using a combination of the black point and the the Alpha channel to generate the colors. Looking at the full colors we have: #6B74B8FC Alpha: #6B -> 42% Color: #74B8FC -> CMYK(138, 69, 0, 3) Hue: 210` Black: 3% #140C131A Alpha: #14 -> 8% Color: #0C131A -> CMYK(138, 69, 0, 230) Hue: 210` Black: 230% If we take the Hue at full intensity and overlay it with the Black at the Alpha, I think that generates the actual color: #6B74B8FC = CMYK(0, 0, 0, 3) @ 43% over CMYK(138, 69, 0, 0) #140C131A = CMYK(0, 0, 0, 230) @ 8% over CMYK(138, 69, 0, 0) Those colors seem accurate when tested on this page: http://colorizer.org/ I also tested against a few of the examples listed here and it seems accurate: http://stackoverflow.com/questions/3560890/vista-7-how-to-get-glass-color It seems like there should be a way to calculate the resulting color and output a simple 6-digit hex color number. Lastly, if you wanted to get the actual transparency of Aero, I believe that is handled by dwmcolor.nIntensity, ColorizationColorBalance http://www.codeproject.com/Articles/610909/Changing-Windows-Aero-Color

Here is a really terrible example that converts DwmGetColorizationColor to a useable RGB color, based on my theory that Black and Alpha are used as an overlay of the Hue at full intensity.

My above theory was very close but is not correct. Microsoft appears to be using an HSV color model, not CMYK. However, I do stand by my assertion that Value is not used "normally" but is instead being rendered as a grayscale overlay over top of the base color, at Alpha transparency. The base color is solved by getting the Hue and Saturation and converting that to RGB with Value @ 100%. So the steps to solve look something like this: dwmColorizerColor --> A1, RGB1 RGB1 --> HSV1 H1,S1,100%V --> RGB2 V1 @ A1 over RGB2 --> RGB3 The final step is to use the Intensity quantity to blend the resulting color with the window frame. If window transparency is disabled, the base color of the frame I believe to be 240 gray, which is the Aero color for -moz-Dialog. So that would look like this: RGB3 @ Intensity as Alpha over rgb(240,240,240) --> RGB4 I have also discovered that the registry value here: HKEY_CURRENT_USER\Software\Microsoft\Windows\DWM\ColorizationColor Always returns the Transparency Disabled value whether transparency is enabled or not. However, from the online documentation it is clear that dwmColorizationColor returns different values. Here are some examples, in each set Transparency Disabled is first: SKY: 6b7ab8fc 140c131a SEA: 8032cdcd 3d0f3c3c LIME: 6697d937 0d0a0f04 SUN: 54fadc0e 0d100e01 PUMPKIN: 80ff9c00 3d4a2d00 RUBY: a8ce0f0f 8f760909 VIOLET: 856e3ba1 4a231333

Fixed calculator for solving DWM colors from ColorizationColor. This would require someone much better at writing code than me to clean up and turn into a patch.

I'm sorry to blow up this mailing list, but here are my final set of calculations, simplified and with notes: function dwmToRgb() { // Input Values var colorizationColor = "a84f1b1b"; // dwmcolor.clrColor = ColorizationColor var colorizationColorBalance = 60; // dwmcolor.nIntensity = ColorizationColorBalance var F = 235; // Frame base grayscale color when Transparency is disabled // Parse the input values var A = Math.round(parseInt(colorizationColor.substr(0,2),16)/2.55)/100; var R1 = parseInt(colorizationColor.substr(2,2), 16); var G1 = parseInt(colorizationColor.substr(4,2), 16); var B1 = parseInt(colorizationColor.substr(6,2), 16); var I = colorizationColorBalance/100; // Solve for HSV Value and pure Hue+Sat var V = Math.max(R1, G1, B1); var R2 = R1*255/V; var G2 = G1*255/V; var B2 = B1*255/V; // Aero Frame Pure Hue: Overlay Value @ Alpha over pure Hue+Sat var R3 = Math.round(V+(R2-V)-((R2-V)*A)); var G3 = Math.round(V+(G2-V)-((G2-V)*A)); var B3 = Math.round(V+(B2-V)-((B2-V)*A)); var hexRGB3 = "#" + ((1 << 24) + (R3 << 16) + (G3 << 8) + B3).toString(16).slice(1); // Aero Frame Composite Color: Overlay RGB3 @ Intensity over Frame base color var R4 = Math.round(R3+(F-R3)-((F-R3)*I)); var G4 = Math.round(G3+(F-G3)-((F-G3)*I)); var B4 = Math.round(B3+(F-B3)-((F-B3)*I)); var hexRGB4 = "#" + ((1 << 24) + (R4 << 16) + (G4 << 8) + B4).toString(16).slice(1); // Aero Toolbar Color: Overlay RGB3 @ max 35% Intensity over Frame base color if (I > 0.35) { I5 = 0.35;} else { I5 = I;} var R5 = Math.round(R3+(F-R3)-((F-R3)*I5)); var G5 = Math.round(G3+(F-G3)-((F-G3)*I5)); var B5 = Math.round(B3+(F-B3)-((F-B3)*I5)); var hexRGB5 = "#" + ((1 << 24) + (R5 << 16) + (G5 << 8) + B5).toString(16).slice(1); } As you can see, there's nothing especially complicated about this and anyone competent in C should be able to write a Core-level patch using this math as a base.

(In reply to patrickjdempsey from comment #30) > Created attachment 8402179 [details] > Aero DWM color solver > > Fixed calculator for solving DWM colors from ColorizationColor. This would > require someone much better at writing code than me to clean up and turn > into a patch. based on a little testing by me, this appears to work on win 8.1. thanks for digging into this Patrick.

(In reply to Jim Mathies [:jimm] from comment #34) > (In reply to patrickjdempsey from comment #30) > > Created attachment 8402179 [details] > > Aero DWM color solver > > > > Fixed calculator for solving DWM colors from ColorizationColor. This would > > require someone much better at writing code than me to clean up and turn > > into a patch. > > based on a little testing by me, this appears to work on win 8.1. thanks for > digging into this Patrick. Hmm lime green doesn't seem to be right in the html calculator. Does the posted html page need updated dwmToRgb calculations?

(In reply to Jim Mathies [:jimm] from comment #35) > Hmm lime green doesn't seem to be right in the html calculator. Does the > posted html page need updated dwmToRgb calculations? When using just the formula from comment 31, it looks good to me. Also for lime green. Nice one, Patrick!

Jim, see if this works any better for you. This is the updated code from comment 31. You can change the DWM color of the Intensity and see the results. Try to match Intensity percentage to the position of the Color Intensity slider in Aero Window Color and Appearance controls.

I really appreciate that you guys bothered to dupe this long-standing bug but never moved forward on completing it. This has been broken since before Firefox 2.0 was released and I spent months working on a solution for the color mixing, for what exactly? For it to end up in Bugzilla limbo-land just because it's no longer an immediate priority for the Default Theme? This is not even laughable development. It's pathetic and sickening. I should have known better than to waste my time here.