Closed Bug 567603 Opened 14 years ago Closed 14 years ago

Selected folders with new messages/mail are hard to read using Windows Classic desktop theme

Categories

(Thunderbird :: Folder and Message Lists, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(blocking-thunderbird3.1 rc1+, thunderbird3.1 rc1-fixed)

RESOLVED FIXED
Thunderbird 3.3a1
Tracking Status
blocking-thunderbird3.1 --- rc1+
thunderbird3.1 --- rc1-fixed

People

(Reporter: rsx11m.pub, Assigned: andreasn)

References

Details

(Keywords: regression, Whiteboard: [fixed 3.1 RC 1 build 3])

Attachments

(11 files)

Bug 562934 changed the appearance of server and folder labels to a hard-wired blue when new messages arrived. This causes problems when a folder is currently selected and new messages arrive. In the case of the Windows Classic desktop theme (other themes may be causing the same issue), name and number of new messages in that folder are hardly visible (medium-light blue on dark blue).
This screen shot demonstrates the issue. On the left, the appearance before
the modification of the label color by bug 562934, the folder name is clearly visible. On the right, the current appearance with hard-to-read label.

Steps to reproduce:

1. Select the Inbox folder so that it is highlighted,
2. send yourself a message and wait until it arrives,
3. watch the folder label almost disappear.

Tested on Windows XP with Windows Classic desktop theme and default settings.
Attached image New messages
Not "just" hard to see, but virtually invisible with my display settings
The obvious problem is that one of the colors is fixed (fonts) whereas the other is based on the desktop theme (background). Thus, either both of them have to be fixed or both of them have to be defined by the desktop theme, right?
According to toolkit bug 563565 (new add-on manager), system colors should be preferred over fixed colors. I'd agree with this opinion. It is hard to tell which color scheme a user chooses, but this choice should be respected.
Well I think there's really two problems here:

1) Selected items should always use the system colors
2) The highlight color should be determined using some kind of luminosity check to ensure that things look sane for all colors. For example: http://www.w3.org/TR/2008/REC-WCAG20-20081211/relative-luminance.xml
Good find, Jim.  Looking at other WCAG found by chasing that link, I ran into <http://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html> which provides a fair amount of context for how to think about this stuff...
One problem in this case is that it's not about the contrast between just two but in fact three colors, as you want to distinguish between folders with and without new messages by color as well. The current scheme even without that is already quite complex (colors for Windows Classic):

 - folder not selected: Black text on white background,
 - folder selected but no focus: Black text on gray background,
 - folder selected and has focus: White text on dark blue background.

Thus, the additional "new-messages" color would need sufficient contrast to either of those. Maybe there is some color arithmetic to provide an offset in one or more color channels for a specific distance from the other colors?
I don't think the selected case needs to use the highlighted color. We can just stick with the system color (usually black/white) in that case. If the folder is currently selected, there are already more obvious indicators that there are new messages since you should be able to see them.
Not quite though, the fixed color: #0066cc; may not work with non-selected folder names either (i.e., the assumption "usually black/white" won't hold). That color has to be derived from a system color in some way, and for all cases, to make sense with any color scheme the user has picked.
I know, that's why I suggested performing a relative luminosity check (probably on a handful of potential highlight colors) to determine what color to use for highlighting when names are de-selected.
attachin a small piece of code to get the WCAG luminosity contrast ratio between two colors, if needed.
This makes the text use -moz-cellhighlighttext when selected, even if there are new messages.
blocking-thunderbird3.1: ? → rc1+
> @@ -221,6 +221,12 @@ treechildren::-moz-tree-cell-text(folder
>    color: #0066cc;

This solves the XP Classic default appearance in attachment 446934 [details],
but would still leave users with a background color of #0066cc in the dark.
So, this helps, but the question is if the other issue should be solved too.
> but would still leave users with a background color of #0066cc in the dark.
... in those cases where the folder doesn't have focus, I have to add.
This patch use -moz-activehyperlinktext, while slightly questionable for this context, it comes with a promise to work against the standard document background, even if that happens to be #0066cc.
http://mdn.beonex.com/en/CSS/color_value#Mozilla_Color_Preference_Extensions

Bryan: what's your take?
Attachment #447364 - Flags: ui-review?(clarkbw)
Attachment #447364 - Flags: review?(bwinton)
Comment on attachment 447364 [details] [diff] [review]
and here is a patch that use a system color value instead

The active link color is supposed to be for when a person is actively clicking on the link.  It gives some differentiation from the normal link color as you press the mouse button.

I feel like -moz-hyperlinktext might be more of what we want instead of the active version.  Did you try that color and it didn't work out?
Comment on attachment 447364 [details] [diff] [review]
and here is a patch that use a system color value instead

The syntax looks good to me, so consider it an r=me with whichever -moz-whatever values you end up using.  (As long as they're valid, of course.  ;)

Later,
Blake.
Attachment #447364 - Flags: review?(bwinton) → review+
Comment on attachment 447364 [details] [diff] [review]
and here is a patch that use a system color value instead

ui-r+ with comment 17 addressed using the non-active color
Attachment #447364 - Flags: ui-review?(clarkbw) → ui-review+
Attached image -moz-hyperlinktext
Sadly, -moz-hyperlink text doesn't look good with the Windows Classic theme either.  This screen shot is from the Windows Classic theme on Windows 7.
Hmm, I think I misinterpreted that.  Looking more closely, I think the -moz-hyperlinktext is actually ok, and there's something wrong in the selected text.  Unfortunately, I have a prior commitment tonight, so I can't keep poking at it, so I think andreasn and Standard8 will need to take another run at it in the morning.  :-(
Out of curiousity, is there any chance that some themes on non-Windows platforms would have the same problem?
Whiteboard: [needs new patch]
This takes into account the selected and selected focus states for a folder with new mail as well, and looking at what toolkit does, this should be correct:

http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/themes/winstripe/global/tree.css#113

http://mxr.mozilla.org/comm-central/source/mozilla/toolkit/themes/winstripe/global/tree.css#139
Comment on attachment 447482 [details] [diff] [review]
slightly updated patch

r=Standard8 for the additional modifications. This looks fine on both the main themes on Windows XP.

I think we now get this out for wider feedback, and so I'm going to say this is ok for the wider audience for us taking into RC 1 build 3, though Bryan can overrule if he feels necessary when he gets up.
Attachment #447482 - Flags: review+
Landed on 1.9.2 and its relbranch:

http://hg.mozilla.org/releases/comm-1.9.2/rev/90c42202fc9e
http://hg.mozilla.org/releases/comm-1.9.2/rev/72cb49ee6ab2

Still need to do a trunk landing when trunk is open.
Assignee: nobody → nisses.mail
Whiteboard: [needs new patch] → [needs landing on trunk]
Whiteboard: [needs landing on trunk] → [needs landing on trunk][fixed RC 1 build 3]
Whiteboard: [needs landing on trunk][fixed RC 1 build 3] → [needs landing on trunk][fixed 3.1 RC 1 build 3]
I've tested the updated appearance with a couple of color schemes coming with the Windows Classic theme, and all of them look fine both when the new-mail folder has focus and when not. I've omitted the third case of a selected folder without focus in these screenshots, those receive the same appearance as the "Unified Folders" label, just with bold font (also, no blue color applied).

Note that the blue color stays blue even in the High Contrast color schemes, which have black backgrounds. That's the only case I could find where it has limits and apparently doesn't adapt to a brighter color for better visibility.
This is certainly an extreme example, but just to show what happens when the desktop theme picks a blue window background. In the case where the folder has focus (left and center) everything is fine. Where the folder has new messages but isn't selected, the colors are almost identical. I couldn't find any item in the Display Setting > Appearance > Advanced which would match the color generated by -moz-hyperlinktext, thus can't tell where it's coming from.
I'm pretty sure -moz-hyperlinktext comes from Mozilla directly. In Firefox, it's the color stored in the preference "browser.anchor_color". There's -moz-nativehyperlinktext, but I don't know how that's derived.
I see, changing that pref works, thanks! So, the problem is solvable also for such backgrounds as long as someone knows where to find the pref setting. It's not in Tools > Options > Display though, thus a bit hard to discover.
Yep, looks good here.
Notice the blue in the account name also. Not sure it did that before, or perhaps I didn't notice, but it's all good.
I'm going to suggest we change -moz-hyperlinktext to -moz-nativehyperlinktext. It appears that this is what Firefox uses for URLs in the awesome bar, and it has the benefit of being derived from a system value, at least on Windows. I have no idea where you set this color in the Windows settings, but -moz-nativehyperlinktext ultimately corresponds to COLOR_HOTLIGHT (see MSDN[1]). -moz-nativehyperlinktext appears to be handled for GTK and (of all things) OS/2 [2].

[1] http://msdn.microsoft.com/en-us/library/ms724371%28v=VS.85%29.aspx
[2] http://mxr.mozilla.org/comm-central/ident?i=eColor__moz_nativehyperlinktext
Folks, I know we haven't marked this as fixed yet - that's just because we haven't landed it on trunk yet - but can we do suggested follows in separate bugs please.
The patch takes care of the appearance issue I've opened this bug for, so
from my point of view this is basically fixed and I would have marked it "verified" if it had been resolved already.

Jim, per Mark's comment not to continue here, I'd suggest that you clone this bug for comment #32 to make the color dependent on the desktop theme as well.
Blocks: 568573
Ok, I filed bug 568573 for the unselected case.
I think this can be checked in on trunk now as well, thus closing the bug.
(In reply to comment #36)
> I think this can be checked in on trunk now as well, thus closing the bug.

Thanks for spotting this!

Checked in on trunk: http://hg.mozilla.org/comm-central/rev/f2274251ce53
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.2a1
Whiteboard: [needs landing on trunk][fixed 3.1 RC 1 build 3]
Whiteboard: [fixed 3.1 RC 1 build 3]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: