Shift+Del doesn't work with IMAP delete model "mark as deleted"



MailNews Core
Networking: IMAP
11 years ago
8 years ago


(Reporter: Tilman Schmidt, Assigned: Bienvenu)


(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)




11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv: Gecko/20080201 SeaMonkey/1.1.8 Mnenhy/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv: Gecko/20080201 SeaMonkey/1.1.8 Mnenhy/

When "mark as deleted" has been selected as the delete action on an IMAP mail account, the Shift+Del key combination ("Delete immediately") does not remove the selected message from view immediately like it does with the "move to trash" model. It is still displayed, just marked as deleted. So there is no difference between Del and Shift+Del in this mode.

This is particularly annoying given that there is still no way of displaying only undeleted mails.

Reproducible: Always

Steps to Reproduce:
1. Start SeaMonkey Mail or Thunderbird.
2. Open an IMAP folder.
3. Select a message.
4. Invoke the "Delete immediately" function by holding down the Shift key and pressing the Delete key.
Actual Results:  
The message appears as deleted, ie. with a strikethrough line and a red cross over the letter icon at the beginning.

Expected Results:  
The message should have disappeared from the list and from the server.

Thunderbird on Linux has the same problem.
Tested with Cyrus IMAP 2.2.12 server.
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)


FWIW: (with |mail.imap.expunge_after_delete = false|)
*"Del" can (mark as) delete and undelete a message.
*"Shift + Del" can only (mark as) delete it.
Assignee: mail → bienvenu
Component: MailNews: Main Mail Window → Networking: IMAP
Depends on: 370509
Product: Mozilla Application Suite → Core
QA Contact: networking.imap
Version: unspecified → Trunk
Ever confirmed: true

Comment 2

10 years ago
Dupe of 399475?


10 years ago
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 399475

Comment 4

10 years ago
this bug is different from bug 399475
Resolution: DUPLICATE → ---

Comment 5

10 years ago
this bug wants shift delete to remove the shift deleted message from the view - expunge would do that, but it would remove all deleted messages, which isn't quite the same thing.

Comment 6

10 years ago
As Nikolay Shopiknoted in bug 399475, RFC4315 implements UIDPLUS allowing selective expunge.

I think the "correct" resolution, which may or may not be overly complex is to check the state of UIDPLUS in the IMAP server's advertised capabilities.  If it exists, expunge on the selected message(s) is performed.  If not, do nothing or alert that the remote server does not support selective expunge.  I would fall back to the current behavior as such an alert box would be useless for most users.

Comment 7

10 years ago
we know currently if a server supports uidplus, since we parse the capabilities and use it for other things.

Even in the non uidplus case, we could still honor the user's request not to show that message by removing the header from the database, but it would get a bit tricky when the user closed down and re-opened that folder - we'd have to remember not to download/show that header, which might be more trouble than it's worth. 

UIDPLUS is fairly widely supported, I think.

Comment 8

10 years ago
Probably even better way is to have Boolean value controlling behavior in such case.


10 years ago
OS: Windows 2000 → All
Hardware: PC → All

Comment 9

10 years ago
Another fall-back option is the ugly "STORE all the deleted messages except those to be deleted, run traditional expunge, DELETE the messages again."  On large folders this runs in to overhead problems.

Comment 10

10 years ago
You almost copied words from RFC :). If you don't mind I paste here original as per RFC behavior.

If the server does not support the UIDPLUS capability, the client should fall back to using the STORE command to temporarily remove the \Deleted flag from messages it does not want to remove, then issuing the EXPUNGE command.  Finally, the client should use the STORE command to restore the \Deleted flag on the messages in which it was temporarily removed.
Alternatively, the client may fall back to using just the EXPUNGE command, risking the unintended removal of some messages.

Comment 11

10 years ago
So after all this, is this a dup of bug 399475?

I think bug 399475 is barking up the wrong tree.  Shift+Delete in regard to implementing UIDPLUS is an enhancement and has no dependency on mail.imap.expunge_after_delete.

Comment 12

10 years ago
No its not, if you didn't notice we removed it as dupe of bug 399475

Comment 13

10 years ago
I understand.  I misread bug 370509 as mail.imap.expunge_after_delete expecting to influence the shift modifier.  As I see, it is influencing shift modifier when expected not to.
Product: Core → MailNews Core
Duplicate of this bug: 535127
Last Resolved: 10 years ago8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 370509
You need to log in before you can comment on or make changes to this bug.