Shift-Delete does not honor mail.imap.expunge_after_delete=true



MailNews Core
Networking: IMAP
11 years ago
2 years ago


(Reporter: Tim K, Unassigned)


(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)




11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20061204 Firefox/
Build Identifier: version 2 beta 2 (20070116)

If I set mail.imap.expunge_after_delete=true via about:config it does what it's meant to do when I click on the Delete button or use the Delete key: the email is moved to Trash, deleted from Inbox and the Inbox expunged right away.

But if I use Shift-Delete which bypasses the Trash, the email is deleted but the Inbox is not expunged, the email is left in the "deleted" state.

Reproducible: Always

Steps to Reproduce:
1. Enable mail.imap.expunge_after_delete=true via about:config
2. Hit Shift-Delete on an email in an IMAP Inbox
3. The message will be left in "deleted" state, the Inbox is NOT expunged
Actual Results:  
The message will be left in "deleted" state, the Inbox is NOT expunged

Expected Results:  

IMAP Inbox should be expunged even when using Shift-Delete

Comment 1

11 years ago
I've been experiencing the same thing for months now since enabling the option on my webclient (WorldClient for MDaemon) to show me IMAP deleted messages - I couldn't figure out why empty folders stated they had messages in them.

I concur that the Shift-Delete function is ignoring the config value which makes no sense if the setting is there - why would you want it working in two different ways at the same time.

In fact if shift-delete is supposed to delete a message with no chance of recovery, I would expect the "expunge" to happen regardless of the config setting. Personally I don't care which, but in my opinion the current coding is wrong.

Please can this be fixed.

Reproduced with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20070314 Thunderbird/2.0pre - Build ID: 2007031404

Comment 2

11 years ago
Could this be placed under a different category as "Installer" may mean this is getting ignored. How about under "Mail Window Front End"?

Still happens in Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/20070427 Thunderbird/ - Build ID: 2007042703
David Bienvenu says next in Bug 220064 Comment #14 on 2007-02-06.
> there's a hidden pref in 2.0 that will turn on expunge after every single
> delete: "mail.imap.expunge_after_delete"
> if you set this to true, we'll issue an expunge after every delete.
Regression? Lack of support logic of this pref in official Tb 2.0.0 release?
Or simply one of many IMAP related problems of Tb

Can you get IMAP protocol log and attach log file to this bug ( mime-type = text/plain, if size is accepted ), in order to see whether failure of EXPUNGE or no EXPUNGE?
"SET NSPR_LOG_MODULES=imap:5" is sufficient for initial analysis.

Changing to Core/Networking IMAP.
Assignee: mscott → bienvenu
Component: Installer → Networking: IMAP
Product: Thunderbird → Core
QA Contact: installer → grylchan
Another question. Is the problem recreated with latest-trunk nightly?
Test with new profile(or after backup of profile) is recommended. 

Comment 5

11 years ago
Strange, I shift-delete an email in my inbox and get:

5292[4ae7740]: entering
5292[4ae7740]:  = currentUrl
5292[4ae7740]: 15 expunge

5292[4ae7740]: ReadNextLine [stream=46070c8 nb=15 needmore=0]
5292[4ae7740]: * 979 EXPUNGE

5292[4ae7740]: ReadNextLine [stream=46070c8 nb=25 needmore=0]
5292[4ae7740]: 15 OK EXPUNGE completed

5292[4ae7740]: 16 UID fetch 3467:* (FLAGS)

5292[4ae7740]: ReadNextLine [stream=46070c8 nb=39 needmore=0]
5292[4ae7740]: * 1009 FETCH (UID 3466 FLAGS (\Seen))

5292[4ae7740]: ReadNextLine [stream=46070c8 nb=23 needmore=0]
5292[4ae7740]: 16 OK FETCH completed

0[25fd08]: close socket connection
2128[45fc348]: ImapThreadMainLoop leaving [this=411b1b8]
0[25fd08]: close socket connection
4480[4ae7888]: ImapThreadMainLoop leaving [this=3baad88]
0[25fd08]: close socket connection
5292[4ae7740]: ImapThreadMainLoop leaving [this=3bacb80]

the email is gone.

then shift-delete another in a sub folder and get:

3552[50c5370]: entering
3552[50c5370]:  = currentUrl
3552[50c5370]: 16 expunge

3552[50c5370]: ReadNextLine [stream=4d78148 nb=25 needmore=0]
3552[50c5370]: 16 OK EXPUNGE completed

3552[50c5370]: 17 UID fetch 3467:* (FLAGS)

3552[50c5370]: ReadNextLine [stream=4d78148 nb=39 needmore=0]
3552[50c5370]: * 1009 FETCH (UID 3466 FLAGS (\Seen))

3552[50c5370]: ReadNextLine [stream=4d78148 nb=23 needmore=0]
3552[50c5370]: 17 OK FETCH completed

0[25fd08]: Beta:TellThreadToDie: close socket connection
4700[4b76250]: ImapThreadMainLoop leaving [this=4652e18]
0[25fd08]: close socket connection
4740[50c5748]: ImapThreadMainLoop leaving [this=4653f38]
0[25fd08]: close socket connection
4904[50c54b8]: ImapThreadMainLoop leaving [this=4651cf8]
0[25fd08]: close socket connection
3552[50c5370]: ImapThreadMainLoop leaving [this=46536a8]

and this one is still there.
Bug 359281 Comment #10 says Bug 265472 introduced mail.imap.expunge_after_delete.  

Comment 7

10 years ago
version 3.0a1pre (2008042403) doesn't honor mail.imap.expunge_after_delete
Ever confirmed: true
Blocks: 423953

Comment 8

10 years ago
this depends on bug 399475 


10 years ago
Depends on: 399475

Comment 9

10 years ago
Should shitf-del really expunge after? I don't know if there is any "selective expunge/compact" - if there isn't all the other deleted msgs would also get removed. 
QA Contact: grylchan → networking.imap

Comment 10

10 years ago
If I correctly understood this can be possible done using UIDPLUS extension, look for RFC4315


10 years ago
Product: Core → MailNews Core
Duplicate of this bug: 423953


8 years ago
Duplicate of this bug: 624836


6 years ago
Assignee: mozilla → nobody

Comment 13

6 years ago
Bug is still present in Thunderbird 17 Beta. Normal deleting with mail.imap.expunge_after_delete=true results in the mail immediately disappearing in other clients, shift-deleting the mail doesn't do so.

Comment 14

2 years ago
Not that I had expected anything else from an organisation that prefers to discuss each bug for at least 10 years before deciding fixing/not fixing it. But just for the record: In Thunderbird 45.2.0 this behavior is unchanged and shift-deleted mails still don't get expunged until you close Thunderbird.
You need to log in before you can comment on or make changes to this bug.