User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy) Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:18.104.22.168) Gecko/20061206 Thunderbird/2.0b1 ID:2006120603 I just downloaded a nightly Thunderbird build to play around with the new Tags feature but I've already run into a problem with it! When I tag a message in my IMAP inbox, then move it to a local folder, the tag is lost. After I re-tag the message, moving it from the local folder back to the IMAP inbox does not remove the tag. aside: can tags become a component for bugzilla? Reproducible: Always Steps to Reproduce: 1. On an IMAP account, tag a message 2. Move the message to a local folder 3. Relabel message 4. Move the message back to an IMAP folder Actual Results: After 2 the message will no longer have a tag. After step 4 it will.
Confirmed on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20061206 Thunderbird/2.0b1 ID:2006120603 But it only applies to custom tags. For the 5 predefined it works as expected. IMAP -> IMAP and POP -> POP works fine. Related: bug 360079
Summary: tags lost by moving message from IMAP to local folder → custom tags lost by moving message from IMAP to local folder
Tags are not lost when moving between folders on the same IMAP server. Not sure about moving between IMAP servers.
one question is - does your server store the keywords on the server? i.e., does it support user-defined keywords. That's how we store tags on an imap server; if the server doesn't support that, we just store the tags in the .msf file, so in theory, we should be able to copy them to the local folder as well. But it would help me to know which code path we're taking.
Looking at the message source, I don't see any header that looks like a tag. The closest thing I see is: X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 on my local messages, but nothing like that on the remote messages. Our IMAP server is an exchange 6.5 server I think. What exactly can I look for in the message source to see if it contains the tag?
you'd need to generate an imap protocol log of a session where you open the folder - http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap
I followed the directions for enabling imap logging in Unix but the log is completely empty. The file got created but nothing is in it. This is what I ran: meyerm@meyerm:~$ export NSPR_LOG_MODULES=protocol:5 meyerm@meyerm:~$ export NSPR_LOG_FILE=~/imap.log meyerm@meyerm:~$ /opt/thunderbird/thunderbird and I also tried using logging level 4 to no avail. What am I doing wrong?
That should be export NSPR_LOG_MODULES=imap:5
Wow, I'm an idiot. Ok, so I've got the log now and although it's hard to follow exactly what's going on, events like this one seem to occur at times when I apply labels to messages: -1294009440[9df30e0]: 9dd6bc8:<mailserver>:S-INBOX:CreateNewLineFromSocket: 20 OK IDLE completed. -1294009440[9df30e0]: 9dd6bc8:<mailserver>:S-INBOX:ProcessCurrentURL: entering -1294009440[9df30e0]: 9dd6bc8:<mailserver>:S-INBOX:ProcessCurrentURL:imap:<mailboxinfo>@<mailserver>:143/customKeywords%3EUID%3E/INBOX%3E9007%3E%3Ejt_staff_-_news: = currentUrl -1294009440[9df30e0]: 9dd6bc8:<mailserver>:S-INBOX:SendData: 21 IDLE -1294009440[9df30e0]: ReadNextLine [stream=9df34c0 nb=41 needmore=0] -1294009440[9df30e0]: 9dd6bc8:<mailserver>:S-INBOX:CreateNewLineFromSocket: + IDLE accepted, awaiting DONE command. -1294009440[9df30e0]: 9dd6bc8:<mailserver>:S-INBOX:SendData: DONE -1294009440[9df30e0]: ReadNextLine [stream=9df34c0 nb=23 needmore=0] I snipped out my server info and mailbox stuff. Is this about what you're looking for? Is there something else I can try to find in the log?
Created attachment 247985 [details] [diff] [review] proposed fix darn, I've had this fix in my tree for a while - I can't find it in bugzilla, so I must have forgotten about it :-(
Assignee: mscott → bienvenu
Status: NEW → ASSIGNED
Attachment #247985 - Flags: superreview?(mscott)
Attachment #247985 - Flags: superreview?(mscott) → superreview+
fixed on trunk and branch
Status: ASSIGNED → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Keywords: fixed126.96.36.199 → verified188.8.131.52
You need to log in before you can comment on or make changes to this bug.