Closed Bug 694090 Opened 13 years ago Closed 13 years ago

undo imap delete to trash causes multiple message when expunge after delete is set

Categories

(MailNews Core :: Backend, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Thunderbird 10.0

People

(Reporter: Bienvenu, Assigned: Bienvenu)

References

(Depends on 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

STR:

Set hidden pref mail.imap.expunge_after_delete to true (I think there are docs out there that tell people to do this in some situations)

Delete an imap message

Undo the delete

Results:

You get two copies of the deleted message, the original, and copy that we make when we do the copy back from the trash folder, after trying to remove the deleted flag from the copy in the inbox failed.

With condstore servers, this is especially annoying, because the original copy doesn't get removed when you re-open the inbox.
Attached patch proposed fix (obsolete) — Splinter Review
This bug mainly affects condstore servers like Zimbra and dovecot since with condstore servers we don't try to fetch headers we don't have unless we've gotten out of sync w.r.t. message counts.

test_imapUndo.js still passes for me with this patch, and it tests several scenarios. I may be able to extend it to include this case w/o too much trouble; I'll check.
Attachment #566694 - Flags: review?(mbanner)
Comment on attachment 566694 [details] [diff] [review]
proposed fix

grumble, this isn't quite right...
Attachment #566694 - Flags: review?(mbanner) → review?
This adds a check to the unit test that we have the expected number of messages after undoing the delete.
Attachment #566694 - Attachment is obsolete: true
Attachment #566694 - Flags: review?
Attachment #566712 - Flags: review?(mbanner)
Comment on attachment 566712 [details] [diff] [review]
fix with tweaked unit test

Review of attachment 566712 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/imap/src/nsImapUndoTxn.cpp
@@ +180,5 @@
>                                                   this, nsnull,
>                                                   m_srcMsgIdString, 
>                                                   kImapMsgDeletedFlag,
>                                                   m_idsAreUids);
> +          finishInOnStopRunningUrl = true;

nit: this is set to true in both parts of the if statement so you could take it outside.
Attachment #566712 - Flags: review?(mbanner) → review+
fixed on trunk - http://hg.mozilla.org/comm-central/rev/4c71825eecd2

I bet Blake is going to miss showing this bug to me every time I see him! Or was that Ludo? :-)
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 10.0
Flags: in-testsuite+
Depends on: 1241524

A bug I reported (namely #1541323) has been marked as a duplicate of this bug (#694090) and I have been asked to report my ISP and mail provider. So: ISP - Plusnet; ail provider for affected messages - sometimes Gmail, sometimes Posteo. I use a VPN.

In my testing thus far, the delay (before the undeleted email re-appears) seems be some 3-10 seconds for Gmail, and some two seconds to over a minute for Posteo.

My server settings for the two accounts - Gmail, Posteo - seem similar. I could provide those settings

If the problem is not with Thunderbird itself, perhaps someone can think of a way in which Thunderbird can minimise the delay or mitigate user confusion.

You need to log in before you can comment on or make changes to this bug.