Closed Bug 220064 Opened 20 years ago Closed 12 years ago

"Move it to the trash folder" should expunge/compact the original folder immediately after deletion

Categories

(MailNews Core :: Networking: IMAP, enhancement)

Product:
MailNews Core
Component:
Networking: IMAP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: scott, Assigned: Bienvenu)

References

(Depends on 1 open bug)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20030916

When an email account is set as IMAP and you select "Move it to the trash
folder" as your delete method it doesn't remove the message from the inbox after
a delete.  

Reproducible: Always

Steps to Reproduce:
1. Receive message in inbox
2. Reply/Get Coffee/Do whatever
3. Delete message

Actual Results:  
a) Message appears to be gone from Inbox and appears IN the trash folder
b) Checking the server shows that the message is actually in both the INBOX and
the Trash.  Message appears to be copied and not moved.


Expected Results:  
The message should leave the inbox and ONLY be in the trash.  If I check the
same account with POP3 on another machine the "deleted" message downloads as if
I hadn't read it.  

If I select "expunge inbox on exit" then the messages leave the inbox, when I
close the application.  I'm not sure if this is expected behavior or not.  I'm
guessing not, because Thunderbird with the exact same settings removes the
messages from the inbox immediately.

It's worth noting that "expunge inbox on exit" is NOT selected by default when
you select that delete method.
Are you sure the message in the INBOX is not "marked for deletion" after you
moved it to the trash?
That is the normal behaviour.  Messages are marked for deletion, and then the
later expunge really deletes them.
I agree that "expunge inbox on exit" should be the default setting.
we expunge the folder when you select the folder and there are > 20 deleted
messages in the folder. So eventually the messages do get deleted. If you want
them deleted immediately, you can compact the folder. Thunderbird doesn't behave
differently, I'm reasonably sure.
I'm reasonably sure that's what is happening.  They're being "marked for
deletion," and then not removed.  That makes sense as far as what's happening,
however the menu selection says "move it to the trash" which makes me believe
it's being removed.

I can't think of a situation where you would you want to move the message to the
trash AND keep it as "deleted" in the inbox.  Especially since once the message
is "deleted" Mozilla refuses to display it again, but it's still on the server.

Selecting "expunge on exit" seems to be a good work around, but the config
option is still confusing and should be reworked a little. Either default to
selecting "expunge on exit" when you select the "move to trash" option, or have
the message really *deleted* from the INBOX immediately when the message is
deleted via the gui. 
*** Bug 267529 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
David, one of the top annoyances users report* with IMAP is the fact the moving
messages to trash still requires additional actions afterwards. This is
especially evident when one uses more than one mail client at the same time. I
for one happen to use both Mail&News and fastmail.fm web-interface and find the
crosslined messages to be a constant nuisance. There are other similar reported
bugs, see 200786, 220064, 249474 and 269048.

It is a real issue that requires some re-thinking. The 20-message-count is
simply not effective for many of us, and the manual Compact Folders is not a
convenient solution either. Please confirm this bug.

Prog.

* http://emailaddresses.com/forum/showthread.php?s=&threadid=32863
Summary: "Move it to the trash folder" does not function as expected → "Move it to the trash folder" should expunge/compact the original folder immediately after deletion
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 18 years ago
Resolution: --- → EXPIRED
Re-opening to keep this important RFE on the radar. See rational in comment #5.

Prog.
Severity: minor → enhancement
Status: RESOLVED → UNCONFIRMED
Hardware: PC → All
Resolution: EXPIRED → ---
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is an annoyance for people that use web-based IMAP clients (such as www.roundcube.net)  If this feature is intended as a safeguard, simply purging it the instant it is verified to have successfully copied to the deleted folder would more than suffice.
This is an annoyance to anyone, since it obscures the behavior of the mailbox. 

Expunge/purge control should be improved and not simply left to automation. While there are external plugins to add this behavior, it should be a built-in behavior. 

For large mailboxes with automatic filters, this results in wasted space where "move" is in reality "Copy to somewhere else, and leave the original where it was but mark it as 'deleted'". This also increases delay on receiving the INBOX folder back from the server, or as has been pointed out causes problems for users who use webmail for mobility as well as Thunderbird at some other place. 

I feel this should be a blocker, because IMAP functionality needs to be vastly improved before most people benefit from a new version of Thunderbird. 
I'll put my support behind this bug as well. This is a major annoyance for me, as I have access to several shared accounts on an Exchange 5.5 server at work.

Unless I specifically remember to empty the Trash after deleting a message, the changes aren't reflected for other people who have access to the same accounts and are using Outlook.

Having to constantly empty the Trash is irritating for me and, for my colleagues using Outlook, confusing. (I've completed and deleted or moved a message, but it's still in the Inbox until I exit Thunderbird.)
Excuse for my poor English.

I also got that bug using Imap server on Thunderbird version 1.5.0.9 (20061207)

When you receive a message in your folder and move it with a "filtering rule" it's  marked as deleted on the receive folder and copy to the other folder, then if you move it to copied folder to trash.. it's copyd a second time and marked as deleted on another folder..
"Delete purge receive mails on exit Mozilla" will not delete mails from the second folder.... 

It's a real problem when you got a Quota IMAP mailbox.. "deleted mails" are not shown and also there's no way (just compact folder but that don't seem to be a good way to do it)to purge them in another folder than trash or "receive" default folder.

Can you please consider this as a real important bug... Imap server is more and more used in Mail server world!

Thanks.
This bug is the only problem I have with Thunderbird; however, it is almost making me use only webmail. Once the message is confirmed to have been moved successfully there is no reason the mesage should remain in the inbox for even 1 second. This bug has existed for 2.5 years, how much longer does this need to go on? Please don't respond by telling us to purge on exit or compact; I for one like to run Thunderbird 24x7 on my desktop so exiting never happens. This is obviously not the behavior intended by the delete flag, even if you don't agree I think there should at least be an option to purge after a successful move to trash.
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.
(In reply to comment #14)
> 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.

Since this is a hidden pref, this makes enabling it a hellish task for system administrators. Will the developers make this a default behavior?
No, we don't have any plans to make this the default behavior - it adds unnecessary server load, among other things.

It's fairly easy for to toggle this pref - go into tools | options | advanced | config editor, type expunge, and toggle the pref. Or provide your own download of Thunderbird which overrides the default pref. Or provide users a user.js with all the custom prefs you want. Or use MCD/auto-config to control all the user prefs you want...
(In reply to comment #16)
> No, we don't have any plans to make this the default behavior - it adds
> unnecessary server load, among other things.
> 
> It's fairly easy for to toggle this pref - go into tools | options | advanced |
> config editor, type expunge, and toggle the pref. Or provide your own download
> of Thunderbird which overrides the default pref. Or provide users a user.js
> with all the custom prefs you want. Or use MCD/auto-config to control all the
> user prefs you want...

Thanks for the reply. While this fix is great, I still think this option should be enabled by default, since users who have a heavy enough load for this to cause problems should be tweaking their settings not normal users. Even if you still don't want this to be the default behavior, you could at least provide an easy to access checkbox for this under preferences.
(In reply to comment #17)
> (In reply to comment #16)
> > No, we don't have any plans to make this the default behavior - it adds
> > unnecessary server load, among other things.
> > 
> > It's fairly easy for to toggle this pref - go into tools | options | advanced |
> > config editor, type expunge, and toggle the pref. Or provide your own download
> > of Thunderbird which overrides the default pref. Or provide users a user.js
> > with all the custom prefs you want. Or use MCD/auto-config to control all the
> > user prefs you want...
> Thanks for the reply. While this fix is great, I still think this option should
> be enabled by default, since users who have a heavy enough load for this to
> cause problems should be tweaking their settings not normal users. Even if you
> still don't want this to be the default behavior, you could at least provide an
> easy to access checkbox for this under preferences.

Agreed.
It's only natural that people generally think the defaults should be the setting they happen to want or use, but the vast majority of users wouldn't want this as a default. Consider a large deployment where IT does not want TB issuing expunges on every delete, bringing down their server. 

We will expunge a folder with more than 20 deleted messages whenever you select the folder in question. So the 24x7 case shouldn't be an issue.

Re UI for this pref, I'm not convinced that a better idea wouldn't be to make sure  that we're issuing expunges in enough situations, e.g., after XX messages have the deleted flag set. 

If someone has a usage scenario where we're never issuing expunges, please let me know. I believe we should generally be issuing expunges fairly regularly.
(In reply to comment #19)
> It's only natural that people generally think the defaults should be the
> setting they happen to want or use, but the vast majority of users wouldn't
> want this as a default. Consider a large deployment where IT does not want TB
> issuing expunges on every delete, bringing down their server.

This would be a specialty case, a home user would want messages expunged on delete; especially if thy have more then one computer accessing the same mailbox. The large deployment would be the one that should vary from the defaults, as previously stated through distributed prefs or custom installs.

> We will expunge a folder with more than 20 deleted messages whenever you select
> the folder in question. So the 24x7 case shouldn't be an issue.

Yes this is better then only on exit and compact, but if you don't delete many messages, like me, the deleted ones could stay on the server for a while.
 
> Re UI for this pref, I'm not convinced that a better idea wouldn't be to make
> sure  that we're issuing expunges in enough situations, e.g., after XX messages
> have the deleted flag set. 

Yes an option like this could actually serve both purposes...
Expunge after XX deleted messages.
20 could be default if you'd like, but 1 could be to expunge on delete.

> If someone has a usage scenario where we're never issuing expunges, please let
> me know. I believe we should generally be issuing expunges fairly regularly.

I can't think of when you'd never expunge, but with the proposed option above 0 could mean never expunge.

I can only see a performance hit on huge distributions with people who delete frequently; however, in my experience most people tend to keep every email sent to them. This is especially true in the business world where people often keep emails to keep a written record of what people have committed to or said.
The current default is fine for almost all users - this is the only complaint I've had about it, other than a deployment trying to work around a bug with a certain mobile device sync program. I realize you care a lot - but there is a pref you can use, and maybe someone will add some UI for it.

The multiple machine accessing the same inbox case works fine with the current setup. I access the same inbox from several different machines. We don't download messages with the deleted flag, so the user doesn't know or care if there are deleted messages left.
Could someone explain to me why expunging causes a problem? Surely stuff always needs to be deleted at some stage and your just delaying the process?

This problems occurs for people using Thunderbird in my old University, where you have a mail quota of 30mb. As you can imagine, you can easily hit that. Thunderbird currently simply can not delete mails because of the way it copies the item to trash. Now, while that may not affect too many curren users, because Thunderbird is primarily used by home users, it seems like a pretty big problem in getting any kind of institution to to implement it.

In essence, Thunderbird completely fails to be useable with a mail system that implements quotas. To be, that's a big bug. Whether or not it needs to be a default or not, I cannot say, but since the option is hidden in Thunderbird 2, leaving it out as a UI option seems careless.
Issuing 20 separate expunge statements to a server instead of one single expunge generates 20 times the client<->server round trips, and a lot more server load.

2.0 has a quota feature where we show you in the status bar when you're getting close to your quota.

Disk space is fairly cheap - a 30MB quota would seem to be the exception rather than the rule.
(In reply to comment #21)
> The current default is fine for almost all users - this is the only complaint
> I've had about it, other than a deployment trying to work around a bug with a
> certain mobile device sync program. I realize you care a lot - but there is a
> pref you can use, and maybe someone will add some UI for it.
> 
> The multiple machine accessing the same inbox case works fine with the current
> setup. I access the same inbox from several different machines. We don't
> download messages with the deleted flag, so the user doesn't know or care if
> there are deleted messages left.

Yes if you are accessing the mailbox with only Thunderbird on all the computers (not the case for me, or most I would guess). For example:

A user has an IMAP webmail client (Roundcube, etc.) and has Thunderbird which they run on their desktop. If the user deletes something on Thunderbird and later checks their mail on the webmail client (away from home maybe?) then they will still see the deleted mail in inbox (albeit flagged for deletion). Not every mail client ignores messages flagged for deletion (only TB in my experience).

(In reply to comment #23)
> Issuing 20 separate expunge statements to a server instead of one single
> expunge generates 20 times the client<->server round trips, and a lot more
> server load.

You are working under the assumption that a user is going to delete 20 emails fairly often, as I have stated before I do not think this is the case. I can only speak from my own experience but I find if you have good SPAM filtering you would only delete 1 or 2 emails a day... if you get allot of email to begin with; most email gets saved. As you said disk space is cheap. Think it this way, look at an HTTP server:

Every page loaded has 1 round trip client<->server. If you are using webmail to delete you need to load the inbox, possibly the message, and then send the deletion signal. That's 3 round trips, I don't know the specifics of the IMAP protocol in terms of the amount of bytes transmitted to expunge, but there is no way that it's larger then 3 full HTTP requests/responses.

The point is TB is the only client that I know of which behaves this way; as far your reasoning for this goes:

I understand what you are saying, but I do not agree. What you think is a common usage, I would find exotic. What you think is abnormal, I think is not. I do not have access to any numbers, but I would assume that TB is mainly used by home users and hobbyists, these users d not have to worry about large infrastructures. If TB is being deployed for a large group where this is a concern, you have pointed out several methods of mass customization. Even in this case I am not certain that you concern is warranted. Yes 20x 1kb is more then 1kb... but 20kb is still practically nothing compared to the size of most messages. I am assuming that the purge command is 1kb or less, but even if it is more it cannot be by much.

This bug was opened 09/23/2003 and has had about 12 people who took the time to register this bug. I personally don't register bug that I can deal with, if I didn't think this was a real problem I wouldn't bother. Simply brushing it off as something that nobody wants because not enough people were irritated enough to find this bug and post is nuts. There is no reason for this to not be in the UI at the very least, more trivial things make it in there.
You know, I am the one that implemented the hidden pref so you could have this behavior, so accusing me of brushing off this issue seems a little unfair.
What if it expunges after 20 messages OR a minimum amount of time since the last expunge. Say it's 10 minutes. If I delete 15 messages in a quick inbox-cleanup, the server won't see 15 expunges (since it's less than 20). But after 10 minutes, since it's been 10 minutes since the last expunge and I haven't hit the 20 message limit yet, it will go ahead and expunge the 15 that are waiting.

I can see a user going weeks without deleting anything, then deleting a small handful. That small handful should be expunged within an appropriate amount of time, whether or not they hit 20 messages.
(In reply to comment #25)
> You know, I am the one that implemented the hidden pref so you could have this
> behavior, so accusing me of brushing off this issue seems a little unfair.

I am sorry if that came off as unfair, I do appreciate what you have done, but I do not think we have what should be there yet.

(In reply to comment #26)
> What if it expunges after 20 messages OR a minimum amount of time since the
> last expunge. Say it's 10 minutes. If I delete 15 messages in a quick
> inbox-cleanup, the server won't see 15 expunges (since it's less than 20). But
> after 10 minutes, since it's been 10 minutes since the last expunge and I
> haven't hit the 20 message limit yet, it will go ahead and expunge the 15 that
> are waiting.
> 
> I can see a user going weeks without deleting anything, then deleting a small
> handful. That small handful should be expunged within an appropriate amount of
> time, whether or not they hit 20 messages.

This idea could work, and it should allay your apprehensions. You could set a time out or number of messages or both.

I did a little research, and although it is not entirely clear, http://www.isi.edu/in-notes/rfc3501.txt seems to state that the intended behavior is to expunge immediately after flagging, unless you are flagging multiple things at once and then expunging. Example:

User selects all messages or a folder and deletes:
1. Flag all messages deleted
2. Expunge

User deletes 1 email:
1. Flag that message
2. Expunge

User deletes 1 email and then another 2 minutes later:
1. Flag that message
2. Expunge
  2 minutes later....
3. Flag that message
4. Expunge
Since this bug was filed, the UIDPLUS extension has been added to IMAP. This offers clients the ability to expunge messages as soon as they are deleted without touching the rest of the folder. I'm firmly of the opinion that, where servers advertise this feature, Thunderbird should use it to tidy up after moving messages.

There are reasons not to expunge an entire folder after moving a message. We know that marking a message as deleted isn't a good idea if you're interested in keeping it - but we must expect users to do this. Some clients present all \Deleted messages in a "virtual trash" folder, so users expect to be able to move messages there and get them back later. If they then use Thunderbird and move messages to a real folder named Trash (or "2007", or anything), we will upset them if we immediately expunge the whole folder.
Why can't the client just notify the server that the message is marked for deletion instead of automatically expunging?  That way all clients and the server would be updated at the same time and can update their views accordingly.
Depends on: 399475
WONTFIX per comment 21?
I have used several different clients for IMAP. In none of these did expunge take effect until after I at least switched the folder if not the application. So saying that delete should automatically expunge the folder is counter to parity with other applications.

Another way to look at it is this: if you were intended to expunge after every delete, why bother making the two operations separate at all? Here's one person you won't find complaining about a WFM resolution.

(In reply to comment #29)
> Why can't the client just notify the server that the message is marked for
> deletion instead of automatically expunging?  That way all clients and the
> server would be updated at the same time and can update their views
> accordingly.

That's what deleting does: mark the message as deleted on the server. Expunge actually deletes messages.
Product: Core → MailNews Core
QA Contact: grylchan → networking.imap
WFM based on prior dev comments - the capability is there if a user wants to enable it
Status: NEW → RESOLVED
Closed: 18 years ago → 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.