362989 - custom tags lost by moving message from IMAP to local folder

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Martin Meyer]

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:1.8.1.1) 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.

Comment 1

[Magnus Melin [:mkmelin]]

Confirmed on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) 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

Comment 2

[Martin Meyer]

Tags are not lost when moving between folders on the same IMAP server. Not sure about moving between IMAP servers.

Comment 3

[David :Bienvenu]

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.

Comment 4

[Martin Meyer]

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?

Comment 5

[David :Bienvenu]

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

Comment 6

[Martin Meyer]

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?

Comment 7

[Magnus Melin [:mkmelin]]

That should be 
export NSPR_LOG_MODULES=imap:5

Comment 8

[Martin Meyer]

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?

Comment 9

[David :Bienvenu]

Attachment: 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 :-(

Comment 10

[David :Bienvenu]

fixed on trunk and branch

Comment 11

[Magnus Melin [:mkmelin]]

Nice!