User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060719 Firefox/1.5.0.5 Build Identifier: version 2 alpha 1 (20060724) zip Testing with a Cyrus (v2.3.6) IMAP account from fastmail.fm, when I tag messages using any of the 5 pre-set tags ("To Do", "Important", etc.), and then go to another folder and come back to the original folder, here's what I find: * In the threadpane, the tagged messages ARE shown in the correct colors (e.g., an "Important" message is shown in red). * However, if I go to Message > Tag, none of the tag names are shown with a checkmark. In other words, that menu makes it look like the message is actually untagged. * Likewise, if I view the messages's full headers in the preview pane, the "Tags" header is now nowhere to be seen. This seems to happen only with the 5 default tags/labels, not with custom-made tags. Reproducible: Always Steps to Reproduce: 1. Using IMAP, tag a message with one of the 5 default tags, such as "Important". 2. Click to another folder and then come back to the original folder. (Or alternatively, exit TB and restart.) 3. Select the message tagged in step 1. 4. There's now nothing to indicate the applied tag except for the message color in the threadpane. Expected Results: Message > Tag should properly show which of the default tags is applied. Likewise, this should also be indicated when viewing the message's full headers.

Confirming, I know Marcia said something about this on IRC the other day...

Something similar also happens when you access your Imap account via Thunderbird from multiple machines. While the message remains in the proper tag color on the machine where you applied the tag, the message does not get color coded when accessing the same Imap mailbox from other computers via Thunderbirds. This used to work in 1.5, though.

Just did some brief testing with winzip "version 2 beta 1 (20061204)", and it seems that the above-mentioned persistence problem is fixed. BUT... There are now other serious problems with tags in IMAP (maybe POP too; I didn't check). What I've noticed: (1) I can't de-tag a message by right-clicking and selecting Tag > Important (or whatever tag is in use). The color of the message in the threadpane momentarily changes, but the tag itself doesn't actually get removed. (2) I can't create a new custom tag via the right-click menu. Everything looked fine up until I clicked on the "OK" button, upon which nothing happened; the dialog would not close. (3) Messages tagged with a custom tag aren't being shown in color in the threadpane, even though the tag does show up in the message headers. I know these should be filed as separate bugs, and maybe they already have been, but I don't have the time to search or to file the separate bugs. Sorry. Sure hope this all can be fixed before TB 2 comes out. I use tags with IMAP all the time, and it would be a shame to see a TB 2 released with this feature badly broken.

The only problem i can reproduce here is (1) of comment #3. (Using todays linux branch build.)

Just did some brief testing with beta 1 rc2 (20061206) winzip, and I'm still seeing (1) and (3) from comment # 3. (2) is now OK. Clarification about (1): this only applies to the 5 default tags (Important, Work, Personal, etc.). Via the right-click menu, the only way I can remove a default tag is by selecting Tag > Remove All Tags. (Key exception: I can remove a default tag only when 2 or more default tags are applied to the message. E.g., when there are 3 default tags applied to the message, I can remove 2 of them but not the last one.)

I can also reproduce (1) but not (3). If a message in a thread (not the head message) is marked, and the thread is then collapsed, the whole thread is not marked. If the head messages is marked, the collapsed thread is marked. As I would expect. Is this what you mean?

(In reply to comment #5) > Clarification about (1): this only applies to the 5 default tags (Important, > Work, Personal, etc.). Via the right-click menu, the only way I can remove a > default tag is by selecting Tag > Remove All Tags. (Key exception: I can remove > a default tag only when 2 or more default tags are applied to the message. > E.g., when there are 3 default tags applied to the message, I can remove 2 of > them but not the last one.) This is my experience exactly. The default tags are the problematic ones. I'm not certain what IMAP server software is running--how can I find out? I have a strong suspicion that at least one of my accounts is via Cyrus IMAP.

(In reply to comment #7) Also see https://bugzilla.mozilla.org/show_bug.cgi?id=342708

I had a little more time to test and so made a new profile (still w/ the 20061206 build), and I'm still seeing both (1) and (3). Clarification about (3): it only seems to be a problem with custom tags made with some colors. I'll attach an image so you can see. (Regarding comment #6: I wasn't viewing the messages threaded, just sorted by date.)

This composite image shows a section of the threadpane (the same 5 messages are shown in each screen-snippet) and part of the message headers, so you can see whether the selected message is tagged. All 5 messages are tagged with a custom tag. The 3 snippets on the left show tagged messages where the tag color is NOT being applied to the message in the threadpane. The 2 on the right show 2 messages where the tag color IS being applied in the threadpane. Apologies for making a mess of this bug, btw.

Seems something changes in the last few days, using Thunderbird/2.0b1 ID:20061209 i can no longer reproduce comment 3 issue (1) either.

I was testing 20061211 on an existing IMAP account, and just fall on comment_#3 bugs (1) and (3) too.

I can confirm behaviour (1) with TB version 2 beta 1 (20061212) on Win XP and an cyrus imap server. After the folder is reopened, the tag for the mail is displayed again. I found out that you can remove additional tags by pressing 1,2,3,4 or 5 (depending on the tag you want to remove) if there are still other tags for this mail left. Even pressing 0 removes all tags. But if there is only one tag, this one can only be removed by pressing the tag number (1,..,5) AND 0 afterwards.

*** Bug 363701 has been marked as a duplicate of this bug. ***

can you try with a recent 2.0 nightly build?

Testing with the 20061216 zip build... I'm no longer seeing (1) from comment #3. Great! But (3), with custom tags, is still a problem for me. As far as I can see, it's not the color of the tag per se that's the problem, but it may be related to the position or original name of the tag. I now have the following custom tags, which appear in this sequence: - Another tag - CustomTag - Tag Y - Random Tag - Super tag - Tag X The first 3 all work fine regardless of colors used, but the latter 3 don't -- when a message is tagged with one or more of those tags, the color doesn't show up in the threadpane. Even if I change the colors they still don't work. In the screenshot I attached earlier, I then had only 4 custom tags, the first 2 of which worked and the latter 2 didn't. (Note that "Tag Y" was originally created as "dog tag" and then renamed, which is probably why it doesn't appear in the correct alphabetical position among the custom tags.)

(In reply to comment #15) > can you try with a recent 2.0 nightly build? (1) from comment #3 now works for me with TB version 2 beta 1 (20061219) on Win XP. Thanks!

I am using TB version 2 beta 1 (20070102) on Windows XP Pro SP2 et al... and having the same problem. A message tagged with 1 does not properly clear when I use 0. It appeared to clear; however, when I return from another folder or after a restart the message was again tagged '1'. Here's what I've discovered. 1. The highlight color for 1 (In my case default Red) does not change from Red to black when I press 0. It does when I un-highlight the message. However when I change folders and return the message is again highlighted 1, i.e. Red again. 2. Pressing the '1' key instead of '0' on a 1-tagged message causes the message to immediately change to un-highlighted and untagged. The tag remains 0, i.e. untagged, thereafter regardless of changing folders, restarting. Note, I did NOT have to also press the 0 key following the tag number key 1.

Just did some quick testing with version 2 beta 2 (20070116) zip, using the same profile as before, and issue (3) from comment #3 and comment #16 no longer seems to be a problem. As far as I can see after 15 minutes of playing around, the colors for *all* tags are working perfectly and I'm thus no longer seeing any of the tag-related issues I brought up in this bug. Woo hoo!

->WFM per comment 19.