IMAP message unexpectedly goes to Trash when attempting to move it back into Inbox
Categories
(MailNews Core :: Networking: IMAP, defect)
Tracking
(Not tracked)
People
(Reporter: gds, Unassigned)
References
Details
Attachments
(1 obsolete file)
I was trying to duplicate (unsuccessfully) Bug 1892385 and noticed another problem. If I move a message from Inbox to folder A the move occurs OK. Then I move the message back to Inbox and this works OK. Then I move the message again to folder A and then back to Inbox and the message goes to Trash. If I try to move the message from Trash to Inbox, it disappears from Trash, but when I go to Inbox it's not there. Then I look back in Trash and it is there again.
The unexpected move to trash is triggered by a onlinemove URL telling the server to move the message from Inbox to Trash. Don't know what is triggering this URL to occur. Don't have any filtering or spam actions set up.
I've seen this with two imap accounts, my primary charter account and icloud account for testing. I haven't tested this yet with any others.
I saw this first with a Jun 30 updated self-built daily (129.0a1). It also occurs with 115.12.0 provided by ubuntu distro.
Just noticed that this may be a duplicate of bug 1399008 and bug 1414733, but not sure.
Edit: Looking closer, I think they are the same bug. The only difference is they report this STR:
- restart tb.
- delete inbox message to trash
- go to trash and drag it back to inbox.
- go to inbox, it's not there.
- go to trash, it's there.
For me I have to do it twice to see a problem:
- restart tb.
- delete inbox message to trash
- go to trash drag it back to inbox
- go to inbox, it's there.
- delete same inbox message to trash
- go to trash and drag it back to inbox
- go to inbox, it's not there.
- go to trash, it's there. Can never drag (or move) message back to inbox.
| Reporter | ||
Comment 1•2 years ago
|
||
This appears to fix it. Not sure why, but long ago (CVS days) someone questioned why the call to GetMoveCoalescer() is here.
Debugging with gdb, it's not clear to me why having m_moveCoalascer true causes a move back to Trash when "classification" is triggered in nsImapMailFolder::PlaybackCoalescedOperations(). Looks like it just checks for junk. But that is where the chain of calls begins that eventually ends up sending an onlinemove (to trash) URL to imap protocol.
| Reporter | ||
Comment 2•2 years ago
|
||
Oh well, diff at comment 1 causes try failure on test_imapFilterActions.js and, even worse, my bug mail is not getting filtered into its folder.
| Reporter | ||
Comment 3•2 years ago
|
||
This is a problem with handling pref mail.server.default.dup_action set to 2. In the code this is nsIMsgIncomingServer::moveDupsToTrash. I must have set this when I was looking at a "remove dups" addon a while back that I've subsequently removed. If I set this back to default 0 the bug doesn't occur.
Don't know why the 2nd move back into Inbox gets detected as a duplicate header (which with pref at 2 causes the message to be moved to trash).
| Reporter | ||
Updated•2 years ago
|
Description
•