Thunderbird 2.0a1 build 20060706 The problem only occurs in IMAP accounts by one of my providers (www.hosteurope.de). 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.
is this still a problem after all our other fixes Alexander? I haven't been able to reproduce it yet.
I'm sorry to say this. Yes it is still/again a problem in all my Hosteurope IMAP accounts - not in my web.de IMAP account. Maybe a checkin for one of the other related bugs caused this problem.
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.
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.
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.
(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.
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.
I'm seeing this bug as well in the nightly Mac OSX builds. That darn 'Important' tag is impossible to get rid of.
Alexander, is this behavior any better for you with the latest round of fixes David's been making?
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)
Alex, sounds like it's time for an IMAP protocol log: http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap 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!
David, ping regarding comment 12 (+11).
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.
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.
(In reply to comment #15) Hmm, the "indication" is in the log-text-file. I discribed every single step number by number.
sorry, didn't see the separate attachment with comments. Thx, I'll look at them.
Bug seems to be fixed in Thunderbird 3.0.* (tested in 3.0.2).
WFM per reporter