Closed Bug 845807 Opened 11 years ago Closed 11 years ago

Blue link text should be lighter by default.

Categories

(Thunderbird :: Message Reader UI, enhancement)

Product:
Thunderbird
Component:
Message Reader UI
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
Thunderbird 22.0

People

(Reporter: jsbruner, Assigned: Paenglab)

References

(
URL
)

Details

(Keywords: fonts)

Attachments

(3 files, 7 obsolete files)

Color preferences in Firefox
4.99 KB, image/png
Details
Patch with color options dialog v3
18.93 KB, patch
Paenglab
: review+
bwinton
: ui-review+
Details | Diff | Splinter Review
screenshot on W7 for easier ui-r
50.75 KB, image/png
Details 
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.
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.
(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.)
(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?
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.
(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.
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.
(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.
(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).
Attached patch Font Change Patch (obsolete) — — Splinter Review 
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.
Assignee: nobody → josiah
Status: NEW → ASSIGNED
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).
(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.
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?
(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.
OS: All → Mac OS X
Attached patch Patch. (obsolete) — — Splinter Review 
Fixed the description and asking for ui-review and review from Blake.
Attachment #719552 - Attachment is obsolete: true
Attachment #719624 - Flags: ui-review?(bwinton)
Attachment #719624 - Flags: review?(bwinton)
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.
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.
(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?
(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 on attachment 719624 [details] [diff] [review]
Patch.

Canceling reviews until later notice.
Attachment #719624 - Flags: ui-review?(bwinton)
Attachment #719624 - Flags: review?(bwinton)
(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?
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.
Component: Message Reader UI → Preferences: Backend
OS: Mac OS X → All
Product: Thunderbird → Core
Attached patch Patch. (obsolete) — — Splinter Review 
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.
Attachment #719624 - Attachment is obsolete: true
Attachment #719987 - Flags: ui-review?(bwinton)
Apparently my patch got messed up. I will upload a new one at a later time...
Attached patch Patch. (obsolete) — — Splinter Review 
Problem fixed. Now changes color correctly.
Attachment #719987 - Attachment is obsolete: true
Attachment #719987 - Flags: ui-review?(bwinton)
Attachment #720014 - Flags: ui-review?(bwinton)
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…
Attachment #720014 - Flags: ui-review?(bwinton) → ui-review?(shorlander)
Attached patch Patch. (obsolete) — — Splinter Review 
Changed color slightly. A little darker now, but not considerably.
Attachment #720014 - Attachment is obsolete: true
Attachment #720014 - Flags: ui-review?(shorlander)
Attachment #722248 - Flags: ui-review?(shorlander)
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.
Attachment #722248 - Flags: ui-review?(shorlander) → ui-review+
Comment on attachment 722248 [details] [diff] [review]
Patch.

Code's fine - if shorlander is happy with this, then I am too.
Attachment #722248 - Flags: review+
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
https://hg.mozilla.org/mozilla-central/rev/6e7e6773c836
https://hg.mozilla.org/mozilla-central/rev/a8088accbcbe
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
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.
(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.
Stephen,

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

-Mike
Flags: needinfo?(shorlander)
(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.
Flags: needinfo?(shorlander)
(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?
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.
(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.
Depends on: 849386
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.
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.
You guys are a bunch of idiots.
Instead of wasting time doing dumb ****, you better look at the horrendous amount of serious bugs.
(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
(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.
(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.
(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.
Status: RESOLVED → REOPENED
Flags: needinfo?(dbaron)
Keywords: checkin-needed
Resolution: FIXED → ---
Whiteboard: [backout]
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?
Component: Preferences: Backend → Theme
Keywords: checkin-needed
Product: Core → Thunderbird
Target Milestone: mozilla22 → ---
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...
Yikes! I thought it was backed out. Adding it back. Thanks for finding that.
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.
Keywords: checkin-needed
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.
Status: REOPENED → NEW
Flags: needinfo?(dbaron)
Flags: in-testsuite+
> (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.
Component: Theme → Message Reader UI
Flags: needinfo?(bwinton)
Whiteboard: [wontfix?]
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.
Status: NEW → RESOLVED
Closed: 11 years ago → 11 years ago
Flags: needinfo?(bwinton)
Resolution: --- → WONTFIX
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.
Status: RESOLVED → REOPENED
Flags: needinfo?(bwinton)
Resolution: WONTFIX → ---
(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.
Adding Andreas and Richard to hear what the rest of TB-UX thinks of changing the link text to a lighter blue…
Flags: needinfo?(bwinton)
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.
Attached patch Patch with color options dialog (obsolete) — — Splinter Review 
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.
Attachment #728647 - Flags: ui-review?(bwinton)
Attachment #728647 - Flags: review?(bwinton)
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....
Attachment #728647 - Flags: review?(bwinton) → review-
(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.
Attachment #728647 - Attachment is obsolete: true
Attachment #728647 - Flags: ui-review?(bwinton)
Attachment #728714 - Flags: ui-review?(bwinton)
Attachment #728714 - Flags: review?(mkmelin+mozilla)
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)
Attachment #728714 - Flags: review?(mkmelin+mozilla) → review+
Attachment #722248 - Attachment is obsolete: true
Assignee: josiah → richard.marti
Status: REOPENED → ASSIGNED
Whiteboard: [wontfix?]
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.
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+
Attachment #728714 - Attachment is obsolete: true
Attachment #728714 - Flags: ui-review?(bwinton)
Attachment #728723 - Flags: ui-review?(bwinton)
Attachment #728723 - Flags: review+
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!
Attachment #728723 - Flags: ui-review?(bwinton) → ui-review+
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/e8c54049eec2
Status: ASSIGNED → RESOLVED
Closed: 11 years ago → 11 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 22.0
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.
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.
Blocks: 855135
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.
Status: RESOLVED → VERIFIED
I've filed Toolkit bug 856016 on extending the colorpicker respectively.
(In reply to rsx11m from comment #72)
> I've filed Toolkit bug 856016 on extending the colorpicker respectively.

Thanks, definitely needed to be done.
See Also: → 855684
See Also: 855684 → 
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?
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.
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.
(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.
(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.
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
Keywords: feature
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: