608792 - Don't use aero-style icons on Windows for non-aero/high-contrast desktop themes

Status: RESOLVED WORKSFORME

(Thunderbird :: Theme, defect)

Description

[rsx11m]

I was wondering why the Shredder nightly builds look different on Windows 7 compared with Windows XP, despite using the Windows Classic desktop theme in both instances. The answer is that Shredder recognizes it's running on a platform which supports aero-style themes, but not that I have chosen the Classic theme which is not an aero theme.

The expectation is that the icons are chosen which match the respective desktop theme, rather than just relying on the underlying OS capabilities.

Comment 1

[rsx11m]

Attachment: Main toolbar on Windows 7 (before bug 545557)

This is an example taken from Windows 7 with the Windows Classic desktop
theme selected. As can be seen, it takes mail-toolbar-aero.png rather than
mail-toolbar.png (and respective folder-column icons) as would be expected.

Comment 2

[rsx11m]

I see, bug 468751 attachment 379402 [details] [diff] [review] patched mail/themes/qute/jar.mn
> +% skin ... os=WINNT osversion>=6

So, that appears to be indeed hard-wired to the OS version and may be harder
to base on the desktop theme (e.g., by some CSS metrics) than I thought... :-\

Comment 3

[Ludovic Hirlimann [:Usul]]

Mass move to the new theme component.

Comment 4

[rsx11m]

Attachment: Main toolbar in High Contrast Theme #1

This is a comparison between the aero theme (redesigned in bug 545557) and the tango icons used for Windows XP (enforced by changing the OSVERSION threshold from 6 to 7). This is a new profile with default Windows 7 display settings.

Using the High Contrast Theme #1, it becomes apparent that this is now also an accessibility issue. The gradients in the icons and the black lettering make the buttons likely difficult to recognize for a visually impaired user, so this should raise the level of importance to solve this bug. The argumentation for bug 549306 similarly applies here as well.

Comment 5

[Richard Marti (:Paenglab)]

bug 545557 was for a parity FF4 (except in XP). FF4 always uses the same button style in every mode (does a bug exists for this on FF4?).

When TB should use the Tango icons in Vista/Win7 in classic/non standard modes, both icon sets must be packed in the aero tree.

I'll let Andreas and Clark decide, what should be done.

Comment 6

[rsx11m]

I've stopped following FF4 front-end development, so I can't tell. I don't see any obligation for TB to follow UX-design decisions made for FF, especially if usability is affected. These are separate applications with different needs.

> When TB should use the Tango icons in Vista/Win7 in classic/non standard modes,
> both icon sets must be packed in the aero tree.

Yes, that's what I've figured too in comment #2 - this makes it a bit more complicated than just adding default-theme rules to the CSS definitions...

Comment 7

[Andreas Nilsson (:andreasn)]

I think there are two different issues here.
One is the fact that we don't change the icons when using classic, but so does none of the other apps such as Explorer, Firefox or others do under Windows 7 when using the classic theme.

The other is the High contrast issue, this could somewhat be fixed if we had a way to detect that a high contrast theme is running, as in bug 425598.

We could possibly do something with the icon colors, if we used svg's, and some color selection in there, but I'm not sure exactly what's the best approach would be to fix that.

Comment 8

[rsx11m]

I would be careful with absolute "for all" statements, one may always find a
"there exists" voiding that.  ;-)

There are plenty of examples where the CSS code distinguishes between the default theme and the classic or any other theme, but I sure agree that resolving the issue for the high-contrast themes should be a priority for accessibility if it cannot be easily solved for the other themes.

Comment 9

[Richard Marti (:Paenglab)]

(In reply to comment #7)
> We could possibly do something with the icon colors, if we used svg's, and some
> color selection in there, but I'm not sure exactly what's the best approach
> would be to fix that.

If it's possible to change svg color with css (I don't know how), this could be a good solution. When the glyphs have the same color as the text, then this could be good readable. For example in high contrast mode yellow text and glyph on black background.

Comment 10

[Andreas Nilsson (:andreasn)]

Yeah, that's what I had in mind too. I think I know how, so I'll assign this bug to myself and try to figure that out.

Comment 11

[rsx11m]

Looking at the patches in bug 545557, a couple of changes to remove gradients and hard-wired colors may already reduce the problem significantly:

For attachment 492159 [details] [diff] [review] (remove gradient from menu bar):
> #mail-toolbox > toolbar:not(:-moz-lwtheme) {
>   -moz-appearance: none;
>   border-style: none;
>   background-color: -moz-Dialog;
>-  background-image: -moz-linear-gradient(rgba(255, 255, 255, 0),
>-                    rgba(255, 255, 255, 0));
>+  background-image: none;
> }

This should apply for both the Windows Classic and High-Contrast themes, where the gradient looks out of place.

It's ok to have the buttons shaded in Windows Classic, but for High-Contrast themes a plain background would be preferable, so:

For attachment 492384 [details] [diff] [review] and similar (no gradient, readable text):
> .toolbarbutton-menubutton-button,
> .toolbarbutton-menubutton-dropmarker,
> .toolbarbutton-1 {
>   -moz-appearance: none;
>   padding: 1px 5px !important;
>-  background: rgba(151, 152, 153, .05)
>-              -moz-linear-gradient(rgba(251, 252, 253, .95),
>-              rgba(246, 247, 248, .47) 49%, rgba(231, 232, 233, .45) 51%,
>-              rgba(225,226,229,.3));
>+  background-color: -moz-Dialog;
>   border-radius: 4.5px;
>   border: 1px solid;
>   border-color: rgba(0,0,0,.12) rgba(0,0,0,.19) rgba(0,0,0,.38);
>   box-shadow: 0 0 0 1px rgba(255, 255, 255, .3) inset,
>               0 0 0 2px rgba(255, 255, 255, .1) inset,
>               0 1px 0 rgba(0, 0, 0, .15);
>-  color: black;
>+  color: -moz-DialogText;
>   text-shadow: 0 0 3px white;
> }

This may require additional changes (e.g., I didn't touch the button borders), but may be a feasible starting point to come up with respective CSS rules.

Comment 12

[rsx11m]

Attachment: userChrome.css workaround

This modifies some elements based on comment #11; it makes menus and buttons easier to read but obviously won't take care of the icons which remain too dark for the High-Contrast themes. It looks decent with the Windows Classic theme as well if one just wants to get rid of the gradients.

Comment 13

[rsx11m]

Attachment: userChrome.css with High Contrast Theme #1

Screenshot of attachment 535879 [details] in action.

Comment 14

[rsx11m]

Another occurrence of a hard-wired "color: black" is in the tab-mail tabs:

> .tabmail-tab {
>   color: -moz-dialogText !important;
> }

Makes the labels consistently yellow in High-Contrast Theme #1, though the light-gray background remains the same (this could be changed similar to the buttons, but the border-color/width styles may need some tweaking).

Comment 15

[rsx11m]

Bug 667248 changed the text color for the toolbar buttons to match the menus, thus they are no longer black on dark gray in the High-Contrast desktop theme but white instead, which improves the situation a bit. However, gradients still make those hard to read, thus you'll still need that part of the workaround at least.

Comment 16

[Petr Vones]

This is still broken in TB 12.0.1. Running it on Aero-capable Windows 7 machine with Windows Classic theme (to disable blurry unreadable fonts) it still offers those black/white icons instead of XP colored ones.

Yes, there are XP theme addons but they have to be kept updated and does not work for Lightning. Another option to run TB in Windows XP SP3 compatibility mode to get the right icons isn't nice solution either.

Would be possible to have a prefs for setting desired TB theme ? All these hardcoded auto-algorithms based on OS version will fail in some situations anyway.

Comment 17

[rsx11m]

Attachment: Main toolbar with TB 17.0.x

Update: This looks better now with High Contrast Theme #1, though there are still some weird shadows on inactive buttons, and the gradient in the tabs may not be optimal for users with visibility problems.

Comment 18

[rsx11m]

(s/visibility/visual/)

The following brute-force userChrome.css rule gets rid of the toolbar gradients:

> toolbox {
>   background-image: none !important;
> }

and should replace the first rule in comment #12 attachment 535879 [details].
Looks better for me also with the Windows Classic theme.

Comment 19

[Petr Vones]

Is there any preference setting to get colorful look on Windows 7 with Windows Classic theme other than setting the Windows XP compatibility mode for the thunderbird.exe process ? I still don't get why the gray theme is forced there while Firefox on the same system looks normal.

I don't want to change any CSS, I just want to (conditionally by a preference setting) turn the Windows 7 detection off.

Comment 20

[rsx11m]

No, there is no preference setting. That would be one way to achieve the goal of this bug, making it configurable to avoid hacking omni.ja (comment #4) or applying selective CSS hacks to get around a variety of issues with the aero theme on non-aero desktops.

Comment 21

[Petr Vones]

(In reply to rsx11m from comment #20)
> No, there is no preference setting. That would be one way to achieve the
> goal of this bug, making it configurable to avoid hacking omni.ja 

Yep. Should I post it as a enhancement request ?

Comment 22

[rsx11m]

If it hasn't been filed yet, sure. Such a switch could also be handled as a solution here in this bug report, and there is another bug report pending on providing an option to switch between monochrome and colorized icons, so that may be partially covered but not that explicitly as an "enable switching between aero and qute themes" request.

Comment 23

[Petr Vones]

Posted as bug 928703

Comment 24

[Richard Marti (:Paenglab)]

Closing this bug as WORKSFORME as the inverted icons are now good readable with high-contrast themes.