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

Status: RESOLVED DUPLICATE of bug 370509

(MailNews Core :: Networking: IMAP, defect)

Description

[Tilman Schmidt]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 Mnenhy/0.7.5.666
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.8.1.12) Gecko/20080201 SeaMonkey/1.1.8 Mnenhy/0.7.5.666

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 2.0.0.12 on Linux has the same problem.
Tested with Cyrus IMAP 2.2.12 server.

Comment 1

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)

Confirming.

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.

Comment 2

[Matt]

Dupe of 399475?
https://bugzilla.mozilla.org/show_bug.cgi?id=399475

Comment 4

[David :Bienvenu]

this bug is different from bug 399475

Comment 5

[David :Bienvenu]

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

[Matt]

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

[David :Bienvenu]

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

[Nikolay Shopik]

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

Comment 9

[Matt]

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

[Nikolay Shopik]

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

[Matt]

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

[Nikolay Shopik]

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

Comment 13

[Matt]

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.