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)
Tracking
(blocking-thunderbird3.1 rc1+, thunderbird3.1 rc1-fixed)
RESOLVED
FIXED
Thunderbird 3.3a1
People
(Reporter: rsx11m.pub, Assigned: andreasn)
References
Details
(Keywords: regression, Whiteboard: [fixed 3.1 RC 1 build 3])
Attachments
(11 files)
15.90 KB,
image/png
|
Details | |
10.18 KB,
image/jpeg
|
Details | |
468 bytes,
text/plain
|
Details | |
680 bytes,
patch
|
Details | Diff | Splinter Review | |
895 bytes,
patch
|
bwinton
:
review+
clarkbw
:
ui-review+
|
Details | Diff | Splinter Review |
1.43 KB,
patch
|
Details | Diff | Splinter Review | |
11.29 KB,
image/png
|
Details | |
1.52 KB,
patch
|
standard8
:
review+
|
Details | Diff | Splinter Review |
10.47 KB,
image/png
|
Details | |
5.08 KB,
image/png
|
Details | |
14.00 KB,
image/jpeg
|
Details |
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.
Comment 2•14 years ago
|
||
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.
Comment 5•14 years ago
|
||
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
Comment 6•14 years ago
|
||
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...
Comment 7•14 years ago
|
||
A few other potentially relevant bits: https://wiki.mozilla.org/User:Harthur/ColorConversion http://harthur.wordpress.com/2010/05/24/black-or-white-text-wcag-vs-neural-networks/
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?
Comment 9•14 years ago
|
||
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.
Reporter | ||
Comment 10•14 years ago
|
||
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.
Comment 11•14 years ago
|
||
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.
Comment 12•14 years ago
|
||
attachin a small piece of code to get the WCAG luminosity contrast ratio between two colors, if needed.
Assignee | ||
Comment 13•14 years ago
|
||
This makes the text use -moz-cellhighlighttext when selected, even if there are new messages.
Updated•14 years ago
|
blocking-thunderbird3.1: ? → rc1+
Reporter | ||
Comment 14•14 years ago
|
||
> @@ -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.
Reporter | ||
Comment 15•14 years ago
|
||
> 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.
Assignee | ||
Comment 16•14 years ago
|
||
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?
Assignee | ||
Updated•14 years ago
|
Attachment #447364 -
Flags: ui-review?(clarkbw)
Attachment #447364 -
Flags: review?(bwinton)
Comment 17•14 years ago
|
||
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 18•14 years ago
|
||
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 19•14 years ago
|
||
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+
Comment 20•14 years ago
|
||
Comment 21•14 years ago
|
||
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.
Comment 22•14 years ago
|
||
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. :-(
Comment 23•14 years ago
|
||
Out of curiousity, is there any chance that some themes on non-Windows platforms would have the same problem?
Whiteboard: [needs new patch]
Assignee | ||
Comment 24•14 years ago
|
||
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 25•14 years ago
|
||
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+
Comment 26•14 years ago
|
||
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
status-thunderbird3.1:
--- → rc1-fixed
Whiteboard: [needs new patch] → [needs landing on trunk]
Updated•14 years ago
|
Whiteboard: [needs landing on trunk] → [needs landing on trunk][fixed RC 1 build 3]
Updated•14 years ago
|
Whiteboard: [needs landing on trunk][fixed RC 1 build 3] → [needs landing on trunk][fixed 3.1 RC 1 build 3]
Reporter | ||
Comment 27•14 years ago
|
||
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.
Reporter | ||
Comment 28•14 years ago
|
||
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.
Comment 29•14 years ago
|
||
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.
Reporter | ||
Comment 30•14 years ago
|
||
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.
Comment 31•14 years ago
|
||
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.
Comment 32•14 years ago
|
||
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
Comment 33•14 years ago
|
||
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.
Reporter | ||
Comment 34•14 years ago
|
||
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.
Comment 35•14 years ago
|
||
Ok, I filed bug 568573 for the unselected case.
Reporter | ||
Comment 36•14 years ago
|
||
I think this can be checked in on trunk now as well, thus closing the bug.
Comment 37•14 years ago
|
||
(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
Updated•14 years ago
|
Whiteboard: [fixed 3.1 RC 1 build 3]
You need to log in
before you can comment on or make changes to this bug.
Description
•