User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729)
Build Identifier: version 188.8.131.52 (20090302)
I was defining several tags of various colors.
I noticed that some of my tag colors do not appear in their color on the Tag 'drop down', NOR do the tags color he message line (Subj From/Date/) in the Messages Window. For some colors, T-Bird 'randomly'(?) chooses to use 'BLACK' instead of the defined color.
I suspect someone is doing the Microsoft-Windows thing and trying to protect me from myself by saying "oh you poor user, you don't know what you are doing by selecting that color because it will be hard to read, so we will ignore your silly color choice and use black instead." This person should be b*tch-slapped, appropriately, and should be told not to do such things 'automatically'.
Let users choose their colors regardless of visibility (I tried to make one color so that messages would *blend* in with my standard background message-pane -- a whitish-grey). I wanted to 'ignore them'. If someone feels that they need to do this "FOR THE CHILDREN", then add a 'safe color' option, and the ability to toggle it -- and even move toward defaulting it to "true" (think of the children!)...but don't default the normal interface to 'ignore user, do something we think it is better for you'.
Of note -- the REAL colors are stored -- just not used on the UI menu nor the list-of-messages window. You can see the tag colors in the header area of the message in its real color. So it may be at the UI level that the 'user-protection' feature is kicking in.
Steps to Reproduce:
1. Create tags of multiple colors (which tags get hidden may depend on themes or such).
2. I used tags:
Important: #FF0000 (Red)
Task: #FF9900 (Orange)
Todo: #0000FF (Blue - ignored)
Note: #00FF00 (Green - ignored)
Personal: #6600CC (Purple)
visuallyignore: #E9E9E9 (light grey - ignored)
tags with '- ignored' in above list show as black in Tag dropdown (right click, Tag message...) and show as black in the message listing. They do show proper colors on the 'Tags: subfield on the header display and when *defining* the tags (i.e. they look fine when you are setting up and defining the tags for usage, just that something disables their being used as 'valid' colors at display time).
Colors displayed as defined (readable or not!)
Give actual colors,
offer 'safe colors' if needed.
Don't ignore user choices by default...
Sev set to 'major', because it is MAJORLY difficult to figure out what is going on and what/which colors are being ignored -- I just thought tags were broken when trying to use "user defined colors" and everyone thought I was 'crazy' :-).
But Wasn't until I tried about 7-10 different colors I realized it was some class of colors that was being disabled -- (just so happened when i defined my own colors (like pure blue or green, they didn't show up as blue or green, so I could never figure out how to get back a blue or green label (not realizing they were 'impure greens/blues')...
Repeat: Severity is set because of difficulty in creating the problem condition -- it's been around/been this way for *years*, so realistically,
if severity was broken down to
(frequency/severity(when it occurs)/priority), I'm assigning it's 'local severity' (though not necessarily a 'global severity which is some confusing combination of 'frequency*severity*priority...ZZZzzz.... ;^)
Feel free to mark down severity to 'normal', but please not minor, it's really a pain when it occurs.
WFM here on
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20090828 Lightning/1.0pre Shredder/3.0b4pre ID:20090828110904
Could you try to see if it still happens with
1. do you use Windows XP with classical theme or others?
2. do you have custom line for tags in you userchrome.css?
I Use XP various XP themes...(not a constant over time)..
Right now using standard XP theme (not classical).
I tried custom line tags -- may still have them.
The problem was specifically related to using __custom colors__ -- ones that
didn't equate to a standard color name "orange, red, brown...etc"
If I use a color with a standard name, it shows up fine...But the custom colors weren't getting colored on the messages. I've worked *around* this problem by using the standard colors and simply avoiding my own colors -- but this, of course, doesn't address the original issue.
Does that help reproduce it? Otherwise, if you think you did something that does fix it and it should be in the currently released build, I can change one of my rules to use a custom color and retry all this.
Walsh do you have same issue also using latest TB 3.0.x release?
RESOLVED INCOMPLETE due to lack of response to previous question. If you feel this change was made in error, please respond to this bug with your reasons why.