Default message tags not shown in header pane



Mail Window Front End
12 years ago
8 years ago


(Reporter: AlexIhrig, Unassigned)


(Blocks: 1 bug)

Windows XP

Firefox Tracking Flags

(Not tracked)



(2 attachments)



12 years ago
Thunderbird 2.0a1 build 20060706

The problem only occurs in IMAP accounts by one of my providers (

Tag a message with one of the default tags. Select another message and reselect the previous message. The tag is shown. Than switch to another folder and reselect the previous folder and tagged message. The tag than is only shown in tags column - not in the header pane.

Individual tags don't have this problem.

No JS errors in error console. Thunderbirds / profile locale don't matter - the problem occurs in en-US Thunderbird with a new clean profile.

Comment 1

12 years ago
is this still a problem after all our other fixes Alexander? I haven't been able to reproduce it yet.

Comment 2

12 years ago
I'm sorry to say this. Yes it is still/again a problem in all my Hosteurope IMAP accounts - not in my IMAP account. Maybe a checkin for one of the other related bugs caused this problem.

Comment 3

12 years ago
Scott this is again a bug because of the locales. It's a pain to use tags with different Thunderbird locales. At the moment I'm not able to find clear reproduceable steps to discribe the behaviour. Everytimes I do something, the behaviour changes :-(

Sometimes tags are correct shown, sometimes they are missing in header pane, sometimes they are shown in the apps locale, sometimes they are shown with mixed (header pane / tags column) locales.

I don't know how the default tags are saved in message DB, but I believe at some point they are saved with locale dependent things. Are they saved with the localized words? IMHO we should NOT have the l10n strings in profiles prefs.js:

user_pref("mailnews.tags.$label1.color", "#FF0000");
user_pref("mailnews.tags.$label1.tag", "Wichtig");
user_pref("mailnews.tags.$label2.color", "#FF9900");
user_pref("mailnews.tags.$label2.tag", "Dienstlich");
user_pref("mailnews.tags.$label3.color", "#009900");
user_pref("mailnews.tags.$label3.tag", "Persönlich");
user_pref("mailnews.tags.$label4.color", "#3333FF");
user_pref("mailnews.tags.$label4.tag", "Zu erledigen");
user_pref("mailnews.tags.$label5.color", "#993399");
user_pref("mailnews.tags.$label5.tag", "Später");

There must be a better way, to get tags locale independent.

Comment 4

11 years ago
I can confirm, on both the Alpha 1 release and the nightlies (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060808 Thunderbird/2.0a1 ID:2006080803, for example). I can reproduce on two different IMAP accounts using Alexander's description.

If I apply two tags, an original like 'Important' and a new one, only the new one will appear in the message header after switching folders. I then remove the new tag, and 'Important' reappears in the header.

Comment 5

11 years ago
I'm also finding that 0 - Remove All Tags doesn't actually remove the tags: if I switch folders and return, they're still there.

Comment 6

11 years ago
(In reply to comment #5)
> I'm also finding that 0 - Remove All Tags doesn't actually remove the tags: if
> I switch folders and return, they're still there.

Actually, this method of using the keyboard command ("0") seems to be more successful now; deselecting the tag via the context-menu does not actually remove the stubborn default tags (eg, 'Important'). The discrepancy between the Tags column and message header still exists, however.

Comment 7

11 years ago
Today I've copied all messages from my IMAP account to an other (new) IMAP account. For all copied messages, the default tags now are shown correct in message header pane.

The problem still exists in this new IMAP account for _new_ tagged messages.

Comment 8

11 years ago
I'm seeing this bug as well in the nightly Mac OSX builds.  That darn 'Important' tag is impossible to get rid of.

Comment 9

11 years ago
Alexander, is this behavior any better for you with the latest round of fixes David's been making?

Comment 10

11 years ago
Oh Scott...

Thunderbird 1.8_Branch 2007010303, IMAP account

- Individual tags without any problems
- multiple default tags sometimes are removed (now from the column AND the header pane) after switching the folder - only one tag remains
- if tags remain all, there are X empty lines for X tags (the tags are listed in one line, but there as many lines as tags) - this is evertimes after switching the folder. After switching the message in a folder, there are no empty lines
- manualy removing one of multiple given tags, reanimates an other tag (it seems they are only "hided" (including the checkmark in contextmenu)

Comment 11

11 years ago
Alex, sounds like it's time for an IMAP protocol log:

Can you find some operation that fails, and reproduce the failure, with logging turned on, and when you attach or e-mail me the log, tell me what you were doing? Thx!

Comment 12

11 years ago
Created attachment 250513 [details]
Log comments text

Here is a level 3 log and my comments.

Comment 13

11 years ago
Created attachment 250516 [details]
IMAP-Log level 3

Comment 14

10 years ago
David, ping regarding comment 12 (+11).

Comment 15

10 years ago
I see the log, but without an indication of what he was doing, and what happened in the UI, it's hard to match what's in the log with any particular problem. It looks like the server supports user-defined keywords just fine, however.

Comment 16

10 years ago
re comment #3, we store the non-localized keywords (e.g., $label1, $label3...) on the server. the ".tag" value, the localized string, is only used for display purporses.

Comment 17

10 years ago
(In reply to comment #15)
Hmm, the "indication" is in the log-text-file. I discribed every single step number by number.

Comment 18

10 years ago
sorry, didn't see the separate attachment with comments. Thx, I'll look at them.
Blocks: 432710


9 years ago
Assignee: mscott → nobody
Target Milestone: Thunderbird2.0 → ---

Comment 19

8 years ago
Bug seems to be fixed in Thunderbird 3.0.* (tested in 3.0.2).

Comment 20

8 years ago
WFM per reporter
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.