For the Mozilla desktop applications it would be helpful when a Media Query would exist that detects the Windows 8 standard theme. Now it uses also -moz-windows-compositor which is optimized for Vista/Win7 with gradients, transparency etc.

I'm not adding a theme related metric since the default theme in Win8 is aero, despite the differences between aero on win7 and win8. So I'm going to add a -moz-windows-version selector/query instead to help clear up the ambiguity.

Aero was removed in Windows 8. The only resemblance is semi-transparent taskbar, but that's pretty much everything. The design was changed to the point where every app designed for Aero Glass doesn't fit the rest of the system in Win8.

(In reply to Peter Henkel [:Terepin] from comment #3) > Aero was removed in Windows 8. The only resemblance is semi-transparent > taskbar, but that's pretty much everything. The design was changed to the > point where every app designed for Aero Glass doesn't fit the rest of the > system in Win8. The desktop renders differently but the theme is still stored in aero.msstyles. We use the theme name for theme detection, so -moz-windows-theme on win8 is still aero.

In Bug 855998 I used this media query construct to apply only on default Win8 theme: @media (-moz-windows-compositor) { @media not all and (-moz-windows-glass) { } } A simpler solution would be helpful.

like - @media (-moz-windows-version: xp,vista,win7,win8, ..) { .. } in addition we still have the theme selectors for xp, default theme detection for all win os, and the recently added glass detection. We're also going to try to get bug 578780 fixed too.

Comment on attachment 751599 [details] [diff] [review] csspatch v.1 Review of attachment 751599 [details] [diff] [review]: ----------------------------------------------------------------- Have we considered implementing this as a cross-platform selector (e.g. -moz-os-version) that we could also use for OS X or Linux in the future? ::: layout/style/nsMediaFeatures.cpp @@ +53,5 @@ > +// Windows version identities used in the -moz-windows-version media query. > +const WindowsVersionName winVersionStrings[] = { > + { LookAndFeel::eWindowsVersion_XP, L"xp" }, > + { LookAndFeel::eWindowsVersion_Vista, L"vista" }, > + { LookAndFeel::eWindowsVersion_Win7, L"win7" }, Driveby naming nit: I would prefer that we used "windows" as the prefix instead of "win" as it's more descriptive and more common in for existing Windows selectors. I also think that we should use the prefix consistently instead of leaving the prefix off of xp and vista especially with a cross-platform selector. e.g. windows-xp, windows-vista, windows-7.

(In reply to Matthew N. [:MattN] from comment #12) > Comment on attachment 751599 [details] [diff] [review] > csspatch v.1 > > Review of attachment 751599 [details] [diff] [review]: > ----------------------------------------------------------------- > > Have we considered implementing this as a cross-platform selector (e.g. > -moz-os-version) that we could also use for OS X or Linux in the future? Not sure how useful that would be on Linux. On OSX we already have the theme selectors, from my understanding those are specific to os versions. We could make the name more generic if you like so that we can add versions on other platforms down the road.

Do we end up exposing these to untrusted content? If so, do we want to?

(In reply to Boris Zbarsky (:bz) from comment #14) > Do we end up exposing these to untrusted content? Yes. > If so, do we want to? Interesting question. I'm not sure what the right answer is here. My personal preference would be that all os specific css that we want in chrome should not since it might be useful to someone for malicious purposes. On the flip side of this we currently expose other os specific queries to content, including glass, win and osx theme info, and theme related os configuration. So it seems we are not too worried about this in general. If it's easy to flip these so they are chrome only, maybe we should file a bug on itemizing everything we currently expose (including these) and flip the switch on anything we don't feel content should know about.

The question is whether we're ok with the fingerprinting aspects of this....

Comment on attachment 751599 [details] [diff] [review] csspatch v.1 OK, I guess while waiting on dbaron here... Why did we need to add these to sSystemMetrics?

So what's the fingerprinting information that would be gained? If there's data here that's not already detectable by the sizes of form controls, what is it? Which version of the OS the user is running (I think it's probably pointless to even try protecting that)? Or configuration choices that they've made? (Merely default vs. non-default, or more than that?) My inclination is probably not to worry about fingerprinting aspects here, though that might depend on answers to the above.

(In reply to Boris Zbarsky (:bz) from comment #17) > Comment on attachment 751599 [details] [diff] [review] > csspatch v.1 > > OK, I guess while waiting on dbaron here... > > Why did we need to add these to sSystemMetrics? So that these work with moz-system-metric support.

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #18) > So what's the fingerprinting information that would be gained? If there's > data here that's not already detectable by the sizes of form controls, what > is it? Which version of the OS the user is running (I think it's probably > pointless to even try protecting that)? Or configuration choices that > they've made? (Merely default vs. non-default, or more than that?) General os version (xp, win7, win8, ..) without any guesswork. That's it.

Comment on attachment 751599 [details] [diff] [review] csspatch v.1 Ah, you want both that _and_ the media query? OK, I guess that works. r=me modulo the fingerprinting concerns, which you should discuss with dbaron.

(In reply to Boris Zbarsky (:bz) from comment #21) > Comment on attachment 751599 [details] [diff] [review] > csspatch v.1 > > Ah, you want both that _and_ the media query? That seems to be standard practice with these? I'll default to your judgement on this.

Makes sense to do the thing other cases are already doing, yeah.

Gentle review ping on Neil.

Updated test page to use more generalized media query constants requested in comment 12.

remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/31f741b111e0 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/87b5a0591aff

(In reply to Mike Conley from comment #24) > Gentle review ping on Neil. So gentle that I never noticed the ping. I did get the usual Bugzilla nag of course, but I was fighting a weird build error in NSS which is why I hadn't got around to doing the review. Sorry about that.

https://hg.mozilla.org/mozilla-central/rev/31f741b111e0 https://hg.mozilla.org/mozilla-central/rev/87b5a0591aff

Added documentation: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#-moz-windows-version and https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/25

(In reply to Jean-Yves Perrier [:teoli] from comment #29) I corrected the property name (-moz-os-version) and values: https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Media_queries#-moz-os-version and https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/25#CSS

The media query doesn't work on Windows 8.1. I'll fill a seperate bug soon.