Last Comment Bug 845807 - Blue link text should be lighter by default.
: Blue link text should be lighter by default.
Status: VERIFIED FIXED
: fonts
Product: Thunderbird
Classification: Client Software
Component: Message Reader UI (show other bugs)
: unspecified
: All All
: -- enhancement (vote)
: Thunderbird 22.0
Assigned To: Richard Marti (:Paenglab)
:
:
Mentors:
http://infinite-josiah.blogspot.com/2...
Depends on: 849386
Blocks: 855135
  Show dependency treegraph
 
Reported: 2013-02-27 06:03 PST by Josiah Bruner [:JosiahOne] (needinfo for responses)
Modified: 2014-10-29 15:00 PDT (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
Color preferences in Firefox (4.99 KB, image/png)
2013-02-27 17:30 PST, rsx11m
no flags Details
Font Change Patch (971 bytes, patch)
2013-02-28 10:00 PST, Josiah Bruner [:JosiahOne] (needinfo for responses)
no flags Details | Diff | Splinter Review
Patch. (969 bytes, patch)
2013-02-28 12:08 PST, Josiah Bruner [:JosiahOne] (needinfo for responses)
no flags Details | Diff | Splinter Review
Patch. (216 bytes, patch)
2013-03-01 08:45 PST, Josiah Bruner [:JosiahOne] (needinfo for responses)
no flags Details | Diff | Splinter Review
Patch. (1.46 KB, patch)
2013-03-01 10:16 PST, Josiah Bruner [:JosiahOne] (needinfo for responses)
no flags Details | Diff | Splinter Review
Patch. (1.46 KB, patch)
2013-03-07 07:19 PST, Josiah Bruner [:JosiahOne] (needinfo for responses)
mconley: review+
shorlander: ui‑review+
Details | Diff | Splinter Review
Patch with color options dialog (17.18 KB, patch)
2013-03-23 11:39 PDT, Richard Marti (:Paenglab)
mkmelin+mozilla: review-
Details | Diff | Splinter Review
Patch with color options dialog v2 (18.81 KB, patch)
2013-03-24 04:45 PDT, Richard Marti (:Paenglab)
mkmelin+mozilla: review+
Details | Diff | Splinter Review
Patch with color options dialog v3 (18.93 KB, patch)
2013-03-24 06:37 PDT, Richard Marti (:Paenglab)
richard.marti: review+
bwinton: ui‑review+
Details | Diff | Splinter Review
screenshot on W7 for easier ui-r (50.75 KB, image/png)
2013-03-24 06:39 PDT, Richard Marti (:Paenglab)
no flags Details

Description Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-27 06:03:57 PST
Note: Part of the blogpost that is being pushed to update TB UI.

http://infinite-josiah.blogspot.com/2013/02/thunderbird-ui-concept.html
===================

Point 1: Blue link text should be lighter by default.

===================

Right now the blue link text in Thunderbird is darker than preferred, and should be slightly lighter. We really want something like Apple's Mail App. The difference in text color is shown in point 1 of the supplied link.

The lighter color especially matters on OS X, where we want to lighten up the theme.
Comment 1 rsx11m 2013-02-27 06:25:24 PST
That dark blue looks fine for me on the Windows Classic desktop theme...

Meaning, it's a matter of personal preference, and it can be modified by changing the browser.anchor_color setting. That's defined in the global preferences, thus unless it's changed for Firefox and SeaMonkey as well, there shouldn't be a solid motivation to just change it for Thunderbird alone.

However, making the browser.anchor_color and browser.visited_color preferences available in the Display options as additional color pickers should be feasible, thus allowing users to change them more easily as they please.
Comment 2 rsx11m 2013-02-27 06:26:37 PST
(alternatively or as an additional option, pick some desktop-theme color as the default, but then this should apply to text and background colors as well.)
Comment 3 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-27 06:27:30 PST
(In reply to rsx11m from comment #1)
> That dark blue looks fine for me on the Windows Classic desktop theme...
> 
> Meaning, it's a matter of personal preference, and it can be modified by
> changing the browser.anchor_color setting. That's defined in the global
> preferences, thus unless it's changed for Firefox and SeaMonkey as well,
> there shouldn't be a solid motivation to just change it for Thunderbird
> alone.
> 
> However, making the browser.anchor_color and browser.visited_color
> preferences available in the Display options as additional color pickers
> should be feasible, thus allowing users to change them more easily as they
> please.

I was wondering about Windows. However, I wonder if we should change it on OS X only then?
Comment 4 rsx11m 2013-02-27 06:31:03 PST
You could have some preprocessor directive in all-thunderbird.js to override that setting for a specific platform, that might work, but again I'm not sure if this is desirable. As for Windows, users of an Aero desktop theme may have different ideas what a good color scheme is than users of the Classic theme.

Adding Blake for some ideas.
Comment 5 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-27 08:24:37 PST
(In reply to rsx11m from comment #4)
> You could have some preprocessor directive in all-thunderbird.js to override
> that setting for a specific platform, that might work, but again I'm not
> sure if this is desirable. As for Windows, users of an Aero desktop theme
> may have different ideas what a good color scheme is than users of the
> Classic theme.
> 
> Adding Blake for some ideas.

I am pretty sure it should be changed at least on OS X by default. How we approach this can be decided though.
Comment 6 rsx11m 2013-02-27 10:20:24 PST
Looking at your blog page, your example uses a gray main font for the text rather than solid black. Naturally, a matching lighter blue looks nicer than the default dark blue. Is this the rendering used for plain-text messages on Mac OSX?

And again, a message may specify such a font color explicitly, but then it should also set the link color (which Thunderbird should honor, but I don't know if it actually does). If I choose View > Message Body As > Simple HTML I'd like to see my default settings, which is a solid black text and solid blue links (which go along fine).

Disclaimer: I'm not a Mac OSX user, but I don't see this as a useful change for either Windows or Linux platforms, especially if it would be for just one application and not all platforms.
Comment 7 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-27 11:12:17 PST
(In reply to rsx11m from comment #6)
> Looking at your blog page, your example uses a gray main font for the text
> rather than solid black. Naturally, a matching lighter blue looks nicer than
> the default dark blue. Is this the rendering used for plain-text messages on
> Mac OSX?
> 
> And again, a message may specify such a font color explicitly, but then it
> should also set the link color (which Thunderbird should honor, but I don't
> know if it actually does). If I choose View > Message Body As > Simple HTML
> I'd like to see my default settings, which is a solid black text and solid
> blue links (which go along fine).
> 
> Disclaimer: I'm not a Mac OSX user, but I don't see this as a useful change
> for either Windows or Linux platforms, especially if it would be for just
> one application and not all platforms.

Sorry, I need to fix that on my post. I want the font to stay black (When I was writing the blog post, my text was black, but my theme changed it after I was done), I simply want to change link text.

If you don't feel it is necessary for other platforms (which seems fine to me), then we should change the default for OS X only. The reason I care about OS X changing is because on OS X users expect a nicer experience.

Let's face it. Window's apps are pretty ugly in general.
Comment 8 rsx11m 2013-02-27 17:30:46 PST
Created attachment 719264 [details]
Color preferences in Firefox

(In reply to rsx11m from comment #1)
> However, making the browser.anchor_color and browser.visited_color preferences
> available in the Display options as additional color pickers should be
> feasible, thus allowing users to change them more easily as they please.

Just to keep this option in mind, here the Colors window as in Firefox, showing the additional options available (as long as they work with mailnews contents).
Comment 9 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-28 10:00:18 PST
Created attachment 719552 [details] [diff] [review]
Font Change Patch

Patch that changes the default link color to a lighter blue on OS X only.

Simply change a pref using ifdef in all-thunderbird.js.
Comment 10 rsx11m 2013-02-28 11:41:03 PST
Comment on attachment 719552 [details] [diff] [review]
Font Change Patch

> 845819: Added grain in Windows/WinAero, Linux

Nit: That's referring to the wrong bug (only relevant for checkin message).
Comment 11 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-28 11:44:28 PST
(In reply to rsx11m from comment #10)
> Comment on attachment 719552 [details] [diff] [review]
> Font Change Patch
> 
> > 845819: Added grain in Windows/WinAero, Linux
> 
> Nit: That's referring to the wrong bug (only relevant for checkin message).

Whoops. Good find. I'll fix that if I update the patch, or before I push.
Comment 12 rsx11m 2013-02-28 11:53:43 PST
You are welcome. Did you mean to ask for review for your patch or is this FYI only at this time to get further feedback?
Comment 13 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-28 12:01:49 PST
(In reply to rsx11m from comment #12)
> You are welcome. Did you mean to ask for review for your patch or is this
> FYI only at this time to get further feedback?

Hmm... I suppose I could get it reviewed now.
Comment 14 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-28 12:08:52 PST
Created attachment 719624 [details] [diff] [review]
Patch.

Fixed the description and asking for ui-review and review from Blake.
Comment 15 Mark Banner (:standard8, afk until Dec) 2013-02-28 12:56:28 PST
Personally, I think we should keep this the same as Firefox so that we are consistent with the colours across the two applications. I can't think of a good reason to change something like the link colour between the two.

If you're going to suggest that we're changing it, I'd rather see this discussed with Firefox UX folks first to get their feedback about changing it in FF as well as TB.
Comment 16 rsx11m 2013-02-28 13:44:06 PST
Another potential issue modifying browser.anchor_color comes into my mind is that (at least on Windows) the color of folders with new mail is set to use -moz-hyperlinktext, though wouldn't be affected by changing it on Mac OSX only as proposed here.

That's treechildren::-moz-tree-cell-text(folderNameCol, newMessages-true) and some others. The pinstripe theme defines that simply as "color: blue;" thus isn't affected.
Comment 17 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-28 13:58:40 PST
(In reply to Mark Banner (:standard8) from comment #15)
> Personally, I think we should keep this the same as Firefox so that we are
> consistent with the colours across the two applications. I can't think of a
> good reason to change something like the link colour between the two.
> 
> If you're going to suggest that we're changing it, I'd rather see this
> discussed with Firefox UX folks first to get their feedback about changing
> it in FF as well as TB.

I personally would love to change it on all platforms, but I'm not sure who to ask about the change. Could you suggest someone, or should I just ask in IRC?
Comment 18 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-28 15:13:20 PST
(In reply to Mark Banner (:standard8) from comment #15)
> Personally, I think we should keep this the same as Firefox so that we are
> consistent with the colours across the two applications. I can't think of a
> good reason to change something like the link colour between the two.
> 
> If you're going to suggest that we're changing it, I'd rather see this
> discussed with Firefox UX folks first to get their feedback about changing
> it in FF as well as TB.

Discussed with UX. We are going to change the link color on all platforms to #008ae5. I'm not sure how best to approach this, since I believe this color is stored in gecko somewhere. Do we change that?

Or do we manually set the color in Firefox and TB separately. Do FX first, and make this bug depend on it?

In the meantime, I guess this bug is on hold, I will update this patch with the new color, but it might mean nothing at all.
Comment 19 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-28 15:14:25 PST
Comment on attachment 719624 [details] [diff] [review]
Patch.

Canceling reviews until later notice.
Comment 20 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-02-28 15:36:59 PST
(In reply to rsx11m from comment #16)
> Another potential issue modifying browser.anchor_color comes into my mind is
> that (at least on Windows) the color of folders with new mail is set to use
> -moz-hyperlinktext, though wouldn't be affected by changing it on Mac OSX
> only as proposed here.
> 
> That's treechildren::-moz-tree-cell-text(folderNameCol, newMessages-true)
> and some others. The pinstripe theme defines that simply as "color: blue;"
> thus isn't affected.

If Windows uses -moz-hyperlinktext then what is the issue? Or are you saying you expect the folder text color to be the same as the link color?
Comment 21 rsx11m 2013-02-28 16:07:31 PST
If you change it for Mac OSX only, then there is no issue as the new-mail highlight color is hard-coded there. If it's changed on all platforms, it has to be ensured that the folder name highlight is still ok on Windows from the UX point of view, or it should be changed to a color different than the link color (which may be a TB-specific follow-up bug).

(In reply to Josiah [:JosiahOne] from comment #18)
> Discussed with UX. We are going to change the link color on all platforms to
> #008ae5. I'm not sure how best to approach this, since I believe this color
> is stored in gecko somewhere. Do we change that?

If it's changed globally, you could move this bug to the Core category and patch  modules/libpref/src/init/all.js instead, then it affects all applications equally unless they decide to override it in the application-specific preferences.

Mark is probably better equipped to say how to proceed.
Comment 22 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-01 08:45:37 PST
Created attachment 719987 [details] [diff] [review]
Patch.

Moved to Core, since we are going to change on all platforms.

Added the patch that changes the default font color to the suggestion from UX.

Waiting for UI-review from Blake.
Comment 23 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-01 08:49:20 PST
Apparently my patch got messed up. I will upload a new one at a later time...
Comment 24 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-01 10:16:09 PST
Created attachment 720014 [details] [diff] [review]
Patch.

Problem fixed. Now changes color correctly.
Comment 25 Blake Winton (:bwinton) (:☕️) 2013-03-01 11:02:34 PST
Comment on attachment 720014 [details] [diff] [review]
Patch.

I'm not a ui-reviewer for Core, but perhaps Stephen has a couple of seconds to spare…
Comment 26 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-07 07:19:32 PST
Created attachment 722248 [details] [diff] [review]
Patch.

Changed color slightly. A little darker now, but not considerably.
Comment 27 Stephen Horlander [:shorlander] 2013-03-07 07:22:13 PST
Comment on attachment 722248 [details] [diff] [review]
Patch.

Review of attachment 722248 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me. A little more subtle and in line with current OS aesthetics than the classic highly saturated violet color.
Comment 28 Mike Conley (:mconley) 2013-03-07 07:38:21 PST
Comment on attachment 722248 [details] [diff] [review]
Patch.

Code's fine - if shorlander is happy with this, then I am too.
Comment 29 Ryan VanderMeulen [:RyanVM] 2013-03-07 14:28:33 PST
https://hg.mozilla.org/integration/mozilla-inbound/rev/6e7e6773c836
Comment 30 Ryan VanderMeulen [:RyanVM] 2013-03-07 15:47:55 PST
And a follow-up fix because widget/tests/test_platform_colors.xul assumed that -moz-hyperlinktext was still rgb(0, 0, 238).
https://hg.mozilla.org/integration/mozilla-inbound/rev/a8088accbcbe
Comment 32 Jim Jeffery not reading bug-mail 1/2/11 2013-03-08 13:08:11 PST
Is this supposed to be on Win7 ?  The lighter color is hideous and if this is for TB and Mac OS only, then somehow it made it into Firefox/Nightly builds.
Comment 33 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-08 13:10:51 PST
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #32)
> Is this supposed to be on Win7 ?  The lighter color is hideous and if this
> is for TB and Mac OS only, then somehow it made it into Firefox/Nightly
> builds.


Could you provide a Screenshot of the issue? It passed ui review, though I am not sure if it was actually tested on Windows.


But the original plan was to change on all platforms. But perhaps it shouldn't be that way.
Comment 34 Mike Conley (:mconley) 2013-03-08 13:19:18 PST
Stephen,

I was under the impression that we wanted to make this change across the board. Can you confirm?

-Mike
Comment 35 Stephen Horlander [:shorlander] 2013-03-08 13:22:01 PST
(In reply to Mike Conley (:mconley) from comment #34)
> Stephen,
> 
> I was under the impression that we wanted to make this change across the
> board. Can you confirm?
> 
> -Mike

This is true. Not really seeing the hideous on Windows.
Comment 36 Jim Jeffery not reading bug-mail 1/2/11 2013-03-08 13:23:54 PST
Original color:
http://i.imgur.com/opSLCkh.jpg
New color:
http://i.imgur.com/ft9qvZa.jpg

Win7 x64 latest hourly build cset:
https://hg.mozilla.org/mozilla-central/rev/af5f267cd6a1

first appeared in cset:
https://hg.mozilla.org/mozilla-central/rev/cb432984d5ce

OK cset, prior to landing of this bug:
https://hg.mozilla.org/mozilla-central/rev/71395a927025
Comment 37 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-08 13:26:58 PST
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #36)
> Original color:
> http://i.imgur.com/opSLCkh.jpg
> New color:
> http://i.imgur.com/ft9qvZa.jpg
> 
> Win7 x64 latest hourly build cset:
> https://hg.mozilla.org/mozilla-central/rev/af5f267cd6a1
> 
> first appeared in cset:
> https://hg.mozilla.org/mozilla-central/rev/cb432984d5ce
> 
> OK cset, prior to landing of this bug:
> https://hg.mozilla.org/mozilla-central/rev/71395a927025

... And the hideousness is where?
Comment 38 Jim Jeffery not reading bug-mail 1/2/11 2013-03-08 13:28:28 PST
The pale blue color of the links is the hideous part.  Its too light IMO.

Changing pref: browser.anchor_color back to: #0000EE restores the original blue.

Seems to me that users should not have to tweak yet another pref to undo changes.
Comment 39 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-08 13:31:49 PST
(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #38)
> The pale blue color of the links is the hideous part.  Its too light IMO.
> 
> Changing pref: browser.anchor_color back to: #0000EE restores the original
> blue.
> 
> Seems to me that users should not have to tweak yet another pref to undo
> changes.

Actually, I must respectively disagree. Changes are inevitable. About 90% of users won't even notice the difference, the rest that really care will change it using Preferences. (No need for about:config)

In the meantime, it makes Fx and TB look more modern and lighter. It appeals more to most users. (Take cues from Apple and Google).

Finally, UX decided it was fine. (More than three people had input, and many colors were suggested). UI-review has be finalized. I suppose if you think it is really going to affect users you can talk to Stephen about it.
Comment 40 Jim Jeffery not reading bug-mail 1/2/11 2013-03-08 13:44:03 PST
Ok.  It just looks out of place when links in other Windows applications are darker blue, and with my, and I'm sure others with older eyes, will see the new style as washed out and pale.

Time will tell how well its accepted or noticed.  I thought something had gone wrong with my monitor when I first saw this today.
Comment 41 David Baron :dbaron: ⌚️UTC-10 2013-03-08 20:14:24 PST
So changes to default values of Gecko prefs like the change made in this patch (whether in all.js or firefox.js, really) ought to have review from appropriate Gecko module owners, because we'll ask questions like:

 * what is the range of default colors in other browsers and across operating systems (in cases where browsers might take their default from an OS setting)?  How far out of the range that is known to be Web-compatible is this change taking us?

 * do we know how many pages on the Web adjust the default background and text colors slightly (or substantially) without adjusting the default link/visited colors, and do we know how this patch will affect them?  (This includes viewing under less-than-ideal lighting conditions, which is common on mobile devices.)

I think this probably ought to be backed out until we have answers to those questions.
Comment 42 Pierre Hardenne 2013-03-08 21:27:44 PST
You guys are a bunch of idiots.
Instead of wasting time doing dumb ****, you better look at the horrendous amount of serious bugs.
Comment 43 Mike Conley (:mconley) 2013-03-08 21:56:42 PST
(In reply to Pierre Hardenne from comment #42)
> You guys are a bunch of idiots.
> Instead of wasting time doing dumb ****, you better look at the horrendous
> amount of serious bugs.

Hi Pierre. Please familiarize yourself with the Bugzilla rules of etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Thanks,

-Mike
Comment 44 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-09 05:01:27 PST
(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #41)
> So changes to default values of Gecko prefs like the change made in this
> patch (whether in all.js or firefox.js, really) ought to have review from
> appropriate Gecko module owners, because we'll ask questions like:
> 
>  * what is the range of default colors in other browsers and across
> operating systems (in cases where browsers might take their default from an
> OS setting)?  How far out of the range that is known to be Web-compatible is
> this change taking us?
> 
>  * do we know how many pages on the Web adjust the default background and
> text colors slightly (or substantially) without adjusting the default
> link/visited colors, and do we know how this patch will affect them?  (This
> includes viewing under less-than-ideal lighting conditions, which is common
> on mobile devices.)
> 
> I think this probably ought to be backed out until we have answers to those
> questions.



I suppose that is fine for now. Someone can go back it out. Whoever feels like it I guess.
Comment 45 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-09 05:08:23 PST
(In reply to Pierre Hardenne from comment #42)
> You guys are a bunch of idiots.
> Instead of wasting time doing dumb ****, you better look at the horrendous
> amount of serious bugs.


I'm sorry buy I must respond to this. 


A. If we were dumb idiots then we wouldn't have Firefox in the first place, please remember that. 


B. Also remember that Mozilla is nonprofit, and I don't believe you have filled bugs, donated, or contributed to the project like the many hard working people here. Hundreds of us work from 6AM-11PM, so be respectful of that. 


C. We do have people working on the severe bugs, but if there is one in particular you want fixed, please file a bug. 


Just be respectful. Thanks.
Comment 46 rsx11m 2013-03-09 06:49:27 PST
(In reply to Ryan VanderMeulen [:RyanVM] from comment #31)
> https://hg.mozilla.org/mozilla-central/rev/6e7e6773c836
> https://hg.mozilla.org/mozilla-central/rev/a8088accbcbe

Reopening for backout per comment #41 and comment #44 to allow for discussion and proper review of this patch.

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #41)
> So changes to default values of Gecko prefs like the change made in this
> patch (whether in all.js or firefox.js, really) ought to have review from
> appropriate Gecko module owners, because we'll ask questions like:

Who should be making this assessment (i.e., which modules are affected here), and given the cross-application UX impact of this change, is any sr advised in addition to a moa?

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #40)
> Ok.  It just looks out of place when links in other Windows applications are
> darker blue, and with my, and I'm sure others with older eyes, will see the
> new style as washed out and pale.

I agree that this needs to be evaluated for accessibility issues. Personally I think that a solid black font and a solid white background should go with a solid blue link color as default, providing the best contrast for visually impaired users (especially when they chose to override page/message styles in the prefs to use the default colors/styles instead).

(In reply to David Baron [:dbaron] (don't cc:, use needinfo? instead) from comment #41)
>  * do we know how many pages on the Web adjust the default background and
> text colors slightly (or substantially) without adjusting the default
> link/visited colors, and do we know how this patch will affect them?

Thunderbird doesn't allow to change anchor colors in its preferences UI, only in the Config Editor.
Comment 47 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-09 08:30:37 PST
In the dependent bug I marked it as resolved. I looked at the font again on poorer monitors/settings, and can see that it does get quite faded. The point of the new color was to make TB feel lighter/updated, Fx was never really an issue. So I am going to un-mark this as core.

So the question now is should we change the color on TB for OS X? Or just forget about this entirely?
Comment 48 rsx11m 2013-03-09 10:06:15 PST
Why did you remove the checkin-needed for the backout? This hasn't been backed out yet in either mozilla-central nor mozilla-inbound, thus bug 849386 isn't resolved at this time. This is getting confusing...
Comment 49 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-09 10:10:18 PST
Yikes! I thought it was backed out. Adding it back. Thanks for finding that.
Comment 50 rsx11m 2013-03-09 10:10:38 PST
Also, to clarify, nobody has won't-fixed it for Core, thus no need to move it back to a single application (see Mark's comment #15 on that approach). There were just some concerns voiced about the review process along with the impression that more discussion is needed whether or not such a change should be performed.
Comment 51 Ryan VanderMeulen [:RyanVM] 2013-03-09 10:46:10 PST
Backed out per comment 41.
https://hg.mozilla.org/integration/mozilla-inbound/rev/1fc2be2d8cb7
Comment 52 Frank Yan (:fryn) 2013-03-09 11:46:51 PST
A desire to change the color for Thunderbird is not sufficient justification for changing the color in Firefox and in Core. The default link color is a *fallback*. It is not supposed to be the prettiest colors, since the color can be easily specified by the page. The default color needs to be accessible and legible for all our users. There are many things that we shouldn't conservative on, but this is one thing for which being conservative is good. Limi (of UX) and I support a WONTFIX for this bug at the Core level and for Firefox. Since this bug was changed to be Thunderbird-specific, I'm leaving it open.

Side note: This rationale is not applicable to more complex *widget* defaults. For example, for HTML5 form widgets, we should be bold in providing the best widgets of any browser, making it easy for web developers to do the right thing and provide users with well-designed interactions out-of-the-box.
Comment 53 rsx11m 2013-03-09 12:31:15 PST
> (In reply to Frank Yan (:fryn) from comment #52) The default link color is a
> *fallback*. It is not supposed to be the prettiest colors, since the color
> can be easily specified by the page. The default color needs to be
> accessible and legible for all our users.

This reasoning makes sense and should equally apply to Thunderbird. Since this is back in Thunderbird territory now, asking Blake for a final UX assessment.
Comment 54 Ryan VanderMeulen [:RyanVM] 2013-03-09 16:06:49 PST
https://hg.mozilla.org/mozilla-central/rev/1fc2be2d8cb7
Comment 55 Blake Winton (:bwinton) (:☕️) 2013-03-18 07:42:07 PDT
While this is true for the web, most people sending html email don't specify different colours for links, so the reasoning doesn't particularly hold.

Having said that, given the surprising amount of resistance to making things prettier for people, I'll go along with the wontfix.
Comment 56 Magnus Melin 2013-03-18 11:52:11 PDT
Huh?
I don't follow the reasoning why it nice by default wasn't ok for core, but at least that *is* easily fixable. For mail you have a fair amount of plan text mails where you can't set a prettier default. Also for html mails it's really not that easy to change colors, and if you do you have to send a lot of extra markup.
Comment 57 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-18 15:48:01 PDT
(In reply to Magnus Melin from comment #56)
> Huh?
> I don't follow the reasoning why it nice by default wasn't ok for core, but
> at least that *is* easily fixable. For mail you have a fair amount of plan
> text mails where you can't set a prettier default. Also for html mails it's
> really not that easy to change colors, and if you do you have to send a lot
> of extra markup.

Very good points. So now really UX needs to decide if they want different link colors on TB and Fx.
Comment 58 Blake Winton (:bwinton) (:☕️) 2013-03-18 18:05:17 PDT
Adding Andreas and Richard to hear what the rest of TB-UX thinks of changing the link text to a lighter blue…
Comment 59 Richard Marti (:Paenglab) 2013-03-19 01:00:21 PDT
I'm also for nicer colored links as default on TB as where are lot more non styled links in mails. But the user should be easier able to change this colors if he don't like them. I propose to implement the FX color preferences (attachment 719264 [details]) in TB together with the link color change.
Comment 60 Richard Marti (:Paenglab) 2013-03-23 11:39:17 PDT
Created attachment 728647 [details] [diff] [review]
Patch with color options dialog

When I'm proposing something then I should also deliver something ;)

This patch sets the lighter link color from last patch only for TB on all platforms and adds the FX Color preferences dialog for an easier color change if someone doesn't like the new color.
Comment 61 Magnus Melin 2013-03-24 03:18:07 PDT
Comment on attachment 728647 [details] [diff] [review]
Patch with color options dialog

Review of attachment 728647 [details] [diff] [review]:
-----------------------------------------------------------------

We should also change the header to be "Fonts & Colors" like firefox.

::: mail/components/preferences/display.xul
@@ +6,5 @@
>  
>  <!DOCTYPE overlay [
>  <!ENTITY % brandDTD SYSTEM "chrome://branding/locale/brand.dtd">
>  <!ENTITY % displayDTD SYSTEM "chrome://messenger/locale/preferences/display.dtd" >
> +<!ENTITY % colorsDTD SYSTEM "chrome://messenger/locale/preferences/colors.dtd" >

suspect this isn't needed, especially as there's no %colorsDTD; beneeth

::: mail/locales/en-US/chrome/messenger/preferences/colors.dtd
@@ +5,5 @@
> +<!ENTITY  colorsDialog.title              "Colors">
> +<!ENTITY  window.width                    "38em">
> +<!ENTITY  window.macWidth                 "41em">
> +
> +<!ENTITY  allowPagesToUse.label           "Allow messages to choose their own colors, instead of my selections above">

Maybe this should be "content to choose it's own colors" instead of "messages ..."

::: mail/locales/en-US/chrome/messenger/preferences/display.dtd
@@ +19,5 @@
>  <!ENTITY color.label                      "Color:">
>  <!ENTITY color.accesskey                  "c">
>  <!ENTITY displayWidth.label               "Plain Text Messages">
>  <!ENTITY displayText.label                "When displaying quoted plain text messages:">
> +<!ENTITY colorButton.label                "Colors…">

splinter doesn't show it, but the ellipsis char here is misencoded or something, so the whole display.dtd wouldn't be read for me, resulting in an entity not found error.

@@ +20,5 @@
>  <!ENTITY color.accesskey                  "c">
>  <!ENTITY displayWidth.label               "Plain Text Messages">
>  <!ENTITY displayText.label                "When displaying quoted plain text messages:">
> +<!ENTITY colorButton.label                "Colors…">
> +<!ENTITY colorButton.accesskey            "C">

C is already taken for the other Colors....
Comment 62 Richard Marti (:Paenglab) 2013-03-24 04:45:51 PDT
Created attachment 728714 [details] [diff] [review]
Patch with color options dialog v2

(In reply to Magnus Melin from comment #61)
> Comment on attachment 728647 [details] [diff] [review]
> Patch with color options dialog
> 
> Review of attachment 728647 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> We should also change the header to be "Fonts & Colors" like firefox.

Done

> ::: mail/components/preferences/display.xul
> > +<!ENTITY % colorsDTD SYSTEM "chrome://messenger/locale/preferences/colors.dtd" >
> 
> suspect this isn't needed, especially as there's no %colorsDTD; beneeth

Correct, this was a remnant from my first tries.

> ::: mail/locales/en-US/chrome/messenger/preferences/colors.dtd
> > +<!ENTITY  allowPagesToUse.label           "Allow messages to choose their own colors, instead of my selections above">
> 
> Maybe this should be "content to choose it's own colors" instead of
> "messages ..."

Changed

> ::: mail/locales/en-US/chrome/messenger/preferences/display.dtd
> > +<!ENTITY colorButton.label                "Colors…">
> 
> splinter doesn't show it, but the ellipsis char here is misencoded or
> something, so the whole display.dtd wouldn't be read for me, resulting in an
> entity not found error.

Something must be gone wrong during patch export. Now it should be okay.

> > +<!ENTITY colorButton.accesskey            "C">
> 
> C is already taken for the other Colors....

I changed the accesskey for the other Colors as all the other accesskeys in this line aren't initial letters and now the Colors button has the same accesskey as in FX.
Comment 63 Magnus Melin 2013-03-24 05:05:37 PDT
Comment on attachment 728714 [details] [diff] [review]
Patch with color options dialog v2

Review of attachment 728714 [details] [diff] [review]:
-----------------------------------------------------------------

::: mail/locales/en-US/chrome/messenger/preferences/colors.dtd
@@ +5,5 @@
> +<!ENTITY  colorsDialog.title              "Colors">
> +<!ENTITY  window.width                    "38em">
> +<!ENTITY  window.macWidth                 "41em">
> +
> +<!ENTITY  allowPagesToUse.label           "Allow content to choose it's own colors, instead of my selections above">

My mistake, but "its"

::: mail/locales/en-US/chrome/messenger/preferences/display.dtd
@@ +16,5 @@
>  <!ENTITY regularSize.label                "Regular">
>  <!ENTITY bigger.label                     "Bigger">
>  <!ENTITY smaller.label                    "Smaller">
>  <!ENTITY color.label                      "Color:">
> +<!ENTITY color1.accesskey                 "o">

Hm, label and accesskey doesn't match now. Probably should change it to color1.label too. But while you're at it, make it quotedTextColor.{label,accesskey} instead. (1 is easily confused with l)
Comment 64 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-24 06:01:37 PDT
Great idea Richard. Thanks for taking this. I haven't had time to look at it, but if you are using a lighter default color then make sure the default color is in the color list.
Comment 65 Richard Marti (:Paenglab) 2013-03-24 06:37:54 PDT
Created attachment 728723 [details] [diff] [review]
Patch with color options dialog v3

Changed color.label and accesskey to quotedTextColor and took the link color which was last checked-in (I must used the wrong patch to copy the color).

Carrying over r+
Comment 66 Richard Marti (:Paenglab) 2013-03-24 06:39:04 PDT
Created attachment 728724 [details]
screenshot on W7 for easier ui-r
Comment 67 Blake Winton (:bwinton) (:☕️) 2013-03-24 19:43:21 PDT
Comment on attachment 728723 [details] [diff] [review]
Patch with color options dialog v3

I've been through this a few times, trying to find something wrong with it, but I just can't.  ;)

ui-r=me, and many thanks!
Comment 68 Mark Banner (:standard8, afk until Dec) 2013-03-26 07:40:59 PDT
https://hg.mozilla.org/comm-central/rev/e8c54049eec2
Comment 69 rsx11m 2013-03-26 11:58:29 PDT
I've just tested this in tinderbox build comm-central-linux64/1364314884 and was surprised at first that changing the color to red worked for build-in pages (such as setting "about:" as the starting page) but that the content was still showing blueish links, even for plain-text messages (in fact, I didn't see any difference between this build and an earlier build prior to the patch). Only after unchecking "Allow content to choose its own colors" the color change also became effective for the links in messages.

Thus, at least on Linux (KDE4), it appears that there is some style imposed on plain-text messages picking some desktop-theme color for the links rather than the preference value.

If someone else can reproduce this, it may be worth a follow-up bug.
Comment 70 rsx11m 2013-03-26 17:16:04 PDT
Indeed, that's hardwired to "color: rgb(32,74,135);" in http://mxr.mozilla.org/comm-central/source/mail/themes/linux/mail/messageBody.css#35 for themes/linux, not for the other themes (Mac OSX has a fixed color for the signature link, though).

I've filed bug 855135 to remove those instances as they obviously do no longer make sense now that the user can expect his or her custom colors to be used.
Comment 71 rsx11m 2013-03-27 08:02:39 PDT
Marking verified fixed as it works fine now with the patch for bug 855135 applied.

(In reply to Josiah Bruner [:JosiahOne] from comment #64)
> ... if you are using a lighter default color then make sure the default
> color is in the color list.

That's a limitation of the Toolkit colorpicker implementation, the old link default wasn't in it either (as evident from the Firefox Colors dialog where no color is selected by default for unvisited and visited links, but black and white are selected when pushing the colorpicker buttons for the text and background colors, respectively).

IMO the colorpicker should have some option default-color attribute where you can pass the defined default pref value and which would be a special option to click to reset any user pref previously selected, but that would have to be filed as a Toolkit/XUL bug.
Comment 72 rsx11m 2013-03-29 06:58:27 PDT
I've filed Toolkit bug 856016 on extending the colorpicker respectively.
Comment 73 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-03-29 07:00:04 PDT
(In reply to rsx11m from comment #72)
> I've filed Toolkit bug 856016 on extending the colorpicker respectively.

Thanks, definitely needed to be done.
Comment 74 DEXTER 2013-11-05 07:47:19 PST
Wow... are you guys seriously changing the blue color ON ALL PLATFORMs because it HAS TO look like Apple mails app?

So when did Steve Jobs take over the thunderbird userinterface designer boss' seat?

Maybe you just need to shutdown the development of Thunderbird completly, and use Apple mail, no?
Comment 75 rsx11m 2013-11-05 07:59:13 PST
Aren't you a little late for the party? That patch is in effect for current releases already.

Anyway, the patch changed the default link color, yes - but it also introduced a new dialog in the preferences to modify it without the need of using the Config Editor. Thus, it shouldn't take you longer than a minute or two to switch it to your preferred color.

And, this bug is closed since March, so technically we are done here.
Comment 76 DEXTER 2013-11-05 08:11:15 PST
The problem is not that you're done here.

The problem is that something changed in Thunderbird that effects ALL platforms, just because to be more like Apple mail.
I don't care what those Apple fans do until I'm not affected by their doing.

But here, I'm very well affected, and since I've just found the bug hence the late reply.

In the future please avoid changing thunderbird on all platforms just to be more conform with Steve Jobs on OSX.
Comment 77 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-11-05 08:14:35 PST
(In reply to DEXTER from comment #76)
> The problem is not that you're done here.
> 
> The problem is that something changed in Thunderbird that effects ALL
> platforms, just because to be more like Apple mail.
> I don't care what those Apple fans do until I'm not affected by their doing.
> 
> But here, I'm very well affected, and since I've just found the bug hence
> the late reply.
> 
> In the future please avoid changing thunderbird on all platforms just to be
> more conform with Steve Jobs on OSX.

It's not a matter of changing all platforms to match OS X, instead it was landed as an aesthetic improvement on all platforms. Whether you agree or not is not our problem.

Bugzilla is for development-related topics, unless you have an actual bug, please refrain from posting comments about your opinion. Just change the font color. Thanks.
Comment 78 DEXTER 2013-11-05 08:27:29 PST
(In reply to Josiah Bruner [:JosiahOne] from comment #77)
> (In reply to DEXTER from comment #76)
> 
> It's not a matter of changing all platforms to match OS X, instead it was
> landed as an aesthetic improvement on all platforms.

Let me quote from your very first, opening comment:
"We really want something like Apple's Mail App."
"The lighter color especially matters on OS X, where we want to lighten up the theme."

So clearly, you wanted something as an aesthetic improvement on all platforms.. Oh yes..

You wanted something that looks exactly like your precious leader's software. Maybe you should just use Apple mail and forget Thunderbird. That would have been a better choice for an improvement on all platforms.

Also.. that is not just my opinion. That's the opinion of a lot of people who are not misguided by Apple's religion, but maybe I'm the only one who is idiot enough to write about it.

Next time maybe you should consider other OSes (like Windows, Linux) before changing something on the UI, or else we can just stop using Thunderbird and start using Apple mail, because that is what you would like this software to be look like.

And don't worry, that was my last comment on this issue.
Comment 79 Josiah Bruner [:JosiahOne] (needinfo for responses) 2013-11-05 08:53:20 PST
Why would a bunch of Thunderbird developers be following Apple as a leader? Your thought process really makes no sense.

But please familiarize yourself with the Bugzilla rules of etiquette: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html. Do not use Bugzilla as a place to rant. If you would like to see a change then please file a bug, if not, then do not spam our inboxes. Failure to comply may lead to account suspension. Thanks,

Josiah Bruner

Note You need to log in before you can comment on or make changes to this bug.