81085 - Remove Priority color from all columns in thread pane

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[jglick]

Reverse of bug 74071

Comment 1

[(not reading, please use [e-mail] instead)]

accepting.

should be a trivial fix, but I've got some crashers to fix first.

I'll get this in real soon.  jglick argument about the sender being able to set 
your colors is very compelling.  it's almost as bad a web site opening a pop-up 
on you.  (and I don't want to be guilty of the mail equivalent of that.)

Comment 2

[Matthew T (active 1999-2002)]

> it's almost as bad a web site opening a pop-up on you.

Actually, it's almost (but not quite) as bad as a Web site specifying its own 
color scheme. (Not quite, because through the Priority field a message has less 
choice in colors than a Web page does.) And how often do we let Web sites 
specify their own color scheme? All the time. Do we have the `Always use my 
colors' pref on by default? No we don't.

I think this RFE is ill-advised. Sure, recipients should be able to change the 
priority of messages they receive (either manually, or using a mail filter); 
but priority, like Web page style, is a negotiated thing. A sender should be 
able to suggest the priority for a message, just as a Web author should be able 
to suggest colors, fonts, etc for a Web page. If you don't want senders to be 
able to specify the color of messages, set up a filter which changes the 
Priority of all incoming mail to Normal.

Given that most users aren't color-blind, they usually won't have the Priority 
column itself shown; but that doesn't mean that the priority of a message 
should be completely hidden from them, when it could be shown quite well using 
color of the text in all the columns.

Comment 3

[Ben Bucksch (:BenB)]

> A sender should be 
> able to suggest the priority for a message, just as a Web author should be
> able to suggest colors, fonts, etc for a Web page

All power to HTML mail! ;-P

> If you don't want senders to be 
> able to specify the color of messages, set up a filter which changes the 
> Priority of all incoming mail to Normal.

Maybe I want to see the Priority, but not *that* eye-popping.

Another reason for fixing this is bug 81292. If we want to fix that bug in the
mid-term, we should fix this one before a user sees it. I am assuming that it
doesn't take much time to fix, e.g. only removing a CSS line or similar.

If it works how I think it does and Seth keeps the logic and just removes the
CSS style, you might be able to achieve keep the functionality with a CSS rule
in your userChrome.css

> they usually won't have the Priority column itself shown

? It's on by default. IIRC, there's a bug about improving it.

Comment 4

[jglick]

This isn't about not allowing senders to set the priority of messages. I agree 
senders should be able to set priority of their messages. This is just about not 
using color for all the columns to indicate priority.  Keep the priority 
indicator but use a less intrustive method that allows recipients the choice to 
not view it if they so choose.

Since color is such a powerful thing, the rfe is about using color for a feature 
which recipients themselves can control (also with another indicator for folks 
with color difficulties).

Comment 5

[Matthew T (active 1999-2002)]

Yes, the Priority column is on by default. Jennifer specified in bug 44669 that 
it should be on by default, while at the same time agreeing that it didn't need 
to be on by default. (I'm still trying to work that one out.) But for all users 
who are not color-blind and who can work out how to customize their thread pane 
columns at all, the `Priority' column will be the first one to be hidden, since 
the column is useless for a very large proportion of messages (those which have 
no priority set). So if priority isn't shown by coloring the other columns, 
then it *will* be as if the author hadn't set it at all.

I see no reason for bug 81292 to be incompatible with showing priority using 
color. As with author style sheets vs. user style sheets on the Web, they are 
complementary. The author suggests a priority when sending the message, and I 
set up rules which may alter that priority for some or all messages. You can't 
rely *just* on recipient-side rules in order to determine the color, though. I 
had no idea, until last week, that the e-mail address
[e-mail] even existed, so I had no reason to set up a rule 
for it. If the message it sent me, `!!! Mailbox size limit exceeded !!!', 
hadn't been colored red (in all columns) by 4.x as a result of its `Highest' 
priority, I would have lost even more e-mail than I did.

Comment 6

[Ben Bucksch (:BenB)]

> since the column is useless for a very large proportion of messages
> (those which have no priority set).

That's why I said above "IIRC, there's a bug about improving it".

> set up rules which may alter that priority for some or all messages

I don't want to alter the priority, I just don't want it to be shown in an
intrusive way.

If you like the priority to be shown by background red, why don't you set up a
filter after bug 81292 has been implemented?
*Maybe* we could even ship with this filter as default. But I (as a user) would
at least have the option to remove it with the UI.

Comment 7

[(not reading, please use [e-mail] instead)]

Attachment: one possible fix

Comment 8

[(not reading, please use [e-mail] instead)]

I've attached one possible way to fix this, by adding a pref.  

using a pref might not be the best solution because there is no UI for the user 
to tweak this.  (doing it in userChrome.css has the same problem, there is no 
ui way to tweak that.)

the default value for the new pref is false, so the priority color only shows 
up in priority column.

no one panic, I have no plans to check this in yet

I'm back to working on some 0.9.1 bugs.  After 0.9.1, we can figure out what to 
do.

Comment 9

[Matthew T (active 1999-2002)]

> That's why I said above "IIRC, there's a bug about improving it".

There's a bug about improving what?

Comment 10

[Håkan Waara]

I don't understand this bug (I blame the poor description).

I love the feature where the row's text is red if the sender set the priority.
Is this bug about removing that?

Don't! Please don't.

Comment 11

[scottputterman]

Yeah, this bugs about removing it.  I'm personally in favor of removing it.  If
there was a pref that would be great but it sounds hard.  I think we should wait
until 81292 (as Ben mentions) is implemented to give the user control over this.
Although we do other things without user approval (such as bolding and
underlining), I believe that changing the color is much more intrusive. For one
column I don't think it's that big of a deal, for the entire row it's much more
noticeable (and unfortunately, the sender's priority and my priority don't often
line up).

Comment 12

[(not reading, please use [e-mail] instead)]

note to putterman:   

I have a fix in hand that make this particular behaviour (whole row, or just
priority column) controlled by a pref.

Comment 13

[selmer (gone)]

Even after this is reduced to just the priority column (yay!) there is still a
conflict with the message highlight color.  One of them needs to change.  (Is
there a bug on that already?)

Comment 14

[scottputterman]

moving to 0.9.3.  

Comment 15

[jglick]

selmer, the other bug is 84807.

Comment 16

[(not reading, please use [e-mail] instead)]

some sort of fix for this bug might have already landed (to threadPane.css)

I'll go double check, and if so, clean up the associated C++ code that needs to 
be removed.

Comment 17

[scottputterman]

moving to 0.9.4

Comment 18

[scottputterman]

moving to 0.9.5

Comment 19

[(not reading, please use [e-mail] instead)]

we should resolve / clean this up when we add labels.

Comment 20

[scottputterman]

reassigning to ssu.

Comment 21

[scottputterman]

If it can get in before 0.9.7 great, but let's figure labels will land after 0.9.6.

Comment 22

[scottputterman]

did this get fixed with the labels checkin?

Comment 23

[Sean Su]

yes, it was fixed when the labels feature landed.  marking this so.

Comment 24

[Olga]

Verified on Win2K, Linux, Mac OSX 02-04-2002 build. No colors for priorities.