User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060712 Thunderbird/2.0a1 ID:2006071204 It seems that a tag applied to a set of messages in one profile is invisible to the profile on another computer (same account on the IMAP server). Once that tag is created in the second profile, it appears on all of the messages to which it was applied in the first profile. Reproducible: Always Steps to Reproduce: 1. Create a tag and apply it to a set of messages. 2. Switch to another profile that uses the same IMAP account. 3. Note that no messages in this profile have that tag applied. 4. In the second profile, create the same tag via the context menu. 5. Note that the tag is now applied to same set of messages as in the first profile. Actual Results: Tags on messages are not visible until that tag is created in the profile. Expected Results: Tags should be visible in another profile whether or not they exist in that profile.

No, you have to define the tags in each profile, by design. They're just prefs so you could copy them around between profiles w/o much problem, or even define them in aaaa.js if you want to share them across profiles.

(In reply to comment #1) > No, you have to define the tags in each profile, by design. They're just prefs > so you could copy them around between profiles w/o much problem, or even define > them in aaaa.js if you want to share them across profiles. I sensed this was the case, but I wasn't sure. It may be too late, but it seems that having to copy tag preferences between profiles (and to new profiles) would be a significant barrier to entry for users: it's certainly a usability 'gotcha'. For IMAP, the tag is on the message, which is on the server. Why not display the tag, even if the color preferences aren't available for a given profile?

sharing info across profiles is a general problem and we would definitely take advantage of a general solution for that for this specific problem. We're not storing the tags on the imap server; we're storing the keys on the server, which aren't the same thing. keys are imap mod utf7; tags are unicode. And if the user renames a tag, we can leave the key alone and just change the mapping from keys to tags. Similarly, if the user deletes a tag, we just have to delete the mapping; we don't need to go through all the messages with that key and remove it. So that's the trade-off we've made.

OK--I follow. Thanks for the detailed explanation.

Would there be a case of deleting a tag, recreating the tag and the key being the same? Therefore having messages tagged incorrectly?

that's a possibility, though the key is constructed from the tag, so they're most likely to be unique. If you add the same tag back, it will be displayed for the messages that have that corresponding key. The user is basically controlling what tags will be displayed - if the user wants to remove a tag from a message, they can do that as well.

This seems to cause some issues for renaming tags: 1. I create a new tag, "Tag 1" 2. I apply that tag to an IMAP message 3. I change the name of the tag to "Tag 2" 4. In another Thunderbird instance I create a tag called "Tag 2" and the tagged IMAP message does not have the tag applied. In fact what I have to do is create the tag in the new Thunderbird instance by its initial name "Tag 1" - then rename it again (I'm guessing copying the configuration will work in this case).

@Chris (Comment 7): I agree. Perhaps this should be a new bug?

Here is a recommendation put tags in its own file and then let people synchronize it across systems if they use more then one. There are a number of synchronization software out there and if it will be in a separate file then it can be moved automatically or manually.

mozilla weave can do it, if somebody code that...

(In reply to comment #10) > mozilla weave can do it, if somebody code that... FTR weave integration is bug 446444.