Closed Bug 360463 Opened 18 years ago Closed 18 years ago

Junk status is lost when moving or deleting a message using IMAP

Categories

(Thunderbird :: General, defect)

Product:
Thunderbird
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: tph, Assigned: Bienvenu)

Details

(Keywords: fixed1.8.1.1)

Attachments

(1 file)

proposed fix
11.46 KB, patch
mscott
: superreview+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla Thunderbird, version 1.5.0.8, build date 2006-10-25

Messages which have been marked as spam lose their junk status if moved to a different folder, independent if this is happening manually or via a filter or vie junk settings. This probably only happens in conjunction with IMAP, perhaps it's even limited to particular IMAP server software. I'm using the server imap.de.aol.com via SSL for security.

Reproducible: Always

Steps to Reproduce:
1. Mark any message as spam.
2. Move it to a different IMAP folder.
3. Open this IMAP folder.

Actual Results:  
The message is no longer marked as spam.

Expected Results:  
It should still be marked.
have you tried this in 2.0/trunk builds? It may already be fixed, if your server doesn't keep track of keywords...
WFM on trunk (though bug 290099 is reproducable).
No I haven't tested this in 2.0 or trunk, just with the current stable release (1.5.0.8). 

I may give it a go, assuming I can safely uninstall by deleting the 2.0/trunk folder.
I've tried it with the installer, same thing. I guess I would have to uninstall v1.5 first? Would I lose my settings, local emails or anything?
either that or the 2.0 nightly build is bad - no, you won't lose any info in your profile.
It was a problem with the localised German build apparently.
I've installed the English v2.0b1pre fine.
The problem still exists in v2.0.

I haven't tried v3.0a1 yet.

Let me rephrase...

The problem that Thunderbird doesn't run at all was due to the localised German build.

The original problem (junk status is lost after moving a message to a different IMAP folder) still exists in the English v2.0.

During instllation of v3 an error occured:
http://pizzahut.portland.co.uk/images/tb3_install_error.png
However the install process completed anyway, and I could start TB v3 fine.

The junk status is still lost when moving a message, so since Magnus wrote that it works for him, I suspect it's indeed down to the server software used or maybe to do with the rather slow response time of the AOL server.

Just to clarify, that IMAP server is NOT mine, it belongs AOL and I have only access to it as client, not as admin.
Confirming that the bug is server dependent.
I've tried it on a different IMAP server, also with SSL, and the junk status is kept even in TB v1.5.
The server which kept the junk status is: mail.messagingengine.com

I can duplicate this using version 2 beta 1 (20061112). I am copying a message from a local folder to an IMAP folder. The IMAP server (hostmonster, which I believe is Exim) supports server flags AFAIK.

Tracing out what is happening with me:

In nsImapMailFolder::CopyMessages:

  if (! (supportedUserFlags & kImapMsgSupportUserFlag)) evaluates as false, so all of the code to set junk info in the database is bypassed, supposedly because we will user server flags. 

Then this code is executed:

  if (!sameServer) 
  {
    rv = CopyMessagesWithStream(srcFolder, messages, isMove, PR_TRUE, msgWindow, listener, allowUndo);
    goto done;
  }

which, because of the "goto done", jumps to the bottom of the function and bypasses the rest of the copy processing.

How are the server flags supposed to be set in a copy operation? I believe that during automatic setting of junk status within an IMAP folder, the flags are set through a call to nsImapProtocol::HeaderFetchCompleted and eventually into nsImapMailFolder::PlaybackCoalescedOperations(). I put a breakpoint in nsImapProtocol::HeaderFetchCompleted, and during the copy operation this was never called.


This may be a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=359339

If you mark bug 360463 as a duplicate, be sure to change the version and OS in bug 359339 to be cross platform (Mac OS and XP) and independent of the TB version (affects 1.5, 2 and 3).
I thought I had a patch out there that fixes this - but I've forgotten the details.
One time it actually worked on the AOL server, too. But that was after I submitted the bug, that's why in the bug description it says "always reproducable". I've since moved back from AOL to FastMail, so you probably won't see me reporting any more on this issue.
Attached patch proposed fix — — Splinter Review 
sorry if I had you review this before - I can't find a bug with this patch attached, so I must have forgotten about it.
Assignee: mscott → bienvenu
Status: UNCONFIRMED → ASSIGNED
Attachment #246101 - Flags: superreview?(mscott)
Attachment #246101 - Flags: superreview?(mscott) → superreview+
fix checked into trunk and 2.0 branch - we probably should open new bugs for remaining issues, if any - this bug is already covering several problems...(copying from local to imap, across imap folders, etc.)
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Keywords: fixed1.8.1 → fixed1.8.1.1
*** Bug 333139 has been marked as a duplicate of this bug. ***
David: I just ran thru the STR on my IMAP Zimbra account, and I don't see the issue resolved - the message does lose its junk status if I move it from my inbox to another folder. Is this expected?  I am testing on a PPC Mac.
i see also the same like marcia on windows tbird 2 RC, so i can confirm this.
Carsten, are you using your own IMAP account, or a mozilla.com imap account? Zimbra strips out the junk and non junk keywords when you move messages - there's not much I can do about it...
david: i used my mozilla.com email account on zimbra, okay so this is server releated :)
This is still 100% reproducible on Courier IMAP, the following version:

* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready. Copyright 1998-2004 Double Precision, Inc.  See COPYING for distribution information.

This is with Thunderbird version 2.0.0.17 (20080914).

David Bienvenu, if you're still following this, I gave you a couple of IMAP accounts to play with on this server a while back (something@jynxy.net). Those will manifest the problem if you want to look at this. Happy to re-create if you no longer have details.

Cheers

Alan
Any remaining issues will almost certainly be fixed on trunk by bug 449768.
Actually I spoke too soon on this. Bug 449768 is currently concerned with maintaining message metadata, but I normally do that only when an entire folder is reindexed. It is a similar but different use case to maintain the information during a move - but I think that needs to be done, not only for the case where flags are lost, but for the more general case where there is additional message metadata in the header that needs to be preserved.
Alan, I seem to be the proponent these days of maintaining junk status. If you can setup an account for me on that server, and email me the details, I'd be happy to check this out, at least on trunk.
I can reproduce this on trunk with the account that Alan sent to me, with a copy from local to imap.

Bug 384853 also describes this issue, though, and is still NEW while this current bug is RESOLVED. Bienvenu requested further comments in a new bug in comment 16, so I'll place any additional comments there.
(In reply to comment #26)
> Bug 384853 also describes this issue, ...

Should we set one of these to RESO DUPL?
(In reply to comment #27)
> (In reply to comment #26)
> > Bug 384853 also describes this issue, ...
> 
> Should we set one of these to RESO DUPL?
No, because this current bug has already had a fix implemented. Followup issues in a separate bug are not considered a dup.

The issues should be resolved in bug 459680, which is the next target in my "preserve message metadata" effort. I sometimes add new bugs to solve fundamental issues rather than hijack one of the bugs describing a symptom.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: