Open Bug 549274 Opened 15 years ago Updated 1 year ago

Drafts not deleted on IMAP after message has been sent (perhaps worse with sendInBackground=true)

Categories

(Thunderbird :: Message Compose Window, defect)

Product:
Thunderbird
Component:
Message Compose Window
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

People

(Reporter: bugzilla, Unassigned)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

imap log
33.63 KB, application/octet-stream
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100216 Thunderbird/3.0.2 When TB is configured to automatically save the message been composed in the draft folder, the autosaved draft isn't deleted once the message has been sent. Same goes for manually saved drafts, but in this case I guess a "deletion confirmation" should be displayed. This is true at least when using IMAP, I don't know what happens when using local folders (I only use IMAP mailboxes). Reproducible: Always
I forgot to mention that I'm using mailnews.sendInBackground = true. I don't know if it's related or not.
[I tend to think this bug belongs in MailNews Core | Composition; anyone care to confirm this?] I notice this behavior in one respect: previously-created auto-saved drafts are not automatically deleted by Thunderbird when the final version is sent. I believe this is by design. This is probably what you are noticing, however. Previously-created manually-saved drafts are likewise not auto-deleted. This is also very likely by design, as you mention. The last auto-created draft, however, or a draft you open to edit and send, is I believe auto-deleted (on open, if you opened an existing draft). Again, this is probably also by design.
Severity: normal → minor
(In reply to comment #2) > [I tend to think this bug belongs in MailNews Core | Composition; anyone care > to confirm this?] I'm sorry if I chose the wrong component. > I notice this behavior in one respect: previously-created auto-saved drafts are > not automatically deleted by Thunderbird when the final version is sent. I > believe this is by design. This is probably what you are noticing, however. Yes, I guess that's what I'm describing. Yet I fail to see the rationale behind this... what's the typical use case this behavior should address? Why is the previously-automatically-saved draft different from the last-automatically-saved draft (once the final message has been sent)? This could also be another kind of bug - why the last-automatically-saved draft does not delete the previously-automatically-saved draft? > Previously-created manually-saved drafts are likewise not auto-deleted. This is > also very likely by design, as you mention. Yep, but again I think that is pretty common (at least it is for me) to delete the drafts once the message has been sent. For the manually-saved ones I guess a prompt would save me the trouble of going to delete manually the drafts, once I'm done. > The last auto-created draft, however, or a draft you open to edit and send, is > I believe auto-deleted (on open, if you opened an existing draft). Again, this > is probably also by design. Yes this works correctly (not on opening but on sending).
(In reply to comment #3) > (In reply to comment #2) > > [I tend to think this bug belongs in MailNews Core | Composition; anyone > > care to confirm this?] > I'm sorry if I chose the wrong component. Not really something to apologize for, in this case: I doubt you *could* have created it in the right component, and in any case I'm unsure myself (otherwise I'd have just moved it there already). But thanks for willingness to learn/be corrected. Much appreciated. > > I notice this behavior in one respect: previously-created auto-saved drafts > > are not automatically deleted by Thunderbird when the final version is > > sent. I believe this is by design. This is probably what you are noticing, > > however. > Yes, I guess that's what I'm describing. Yet I fail to see the rationale > behind this... what's the typical use case this behavior should address? Why > is the previously-automatically-saved draft different from the > last-automatically-saved draft (once the final message has been sent)? This > could also be another kind of bug - why the last-automatically-saved draft > does not delete the previously-automatically-saved draft? My own use case is to keep track of previous versions of (especially important or complex) emails that I later sent. I don't know for sure if this is intended behavior, serendipity from a feature intended to do something else, or serendipity from a bug that no one ever cared to fix. (This looks at least partly like bug 382517.) > Yep, but again I think that is pretty common (at least it is for me) to delete > the drafts once the message has been sent. For the manually-saved ones I guess > a prompt would save me the trouble of going to delete manually the drafts, > once I'm done. This is probably a job for an extension, but since that doesn't seem to be the main focus of this bug, it's not (too big of) a problem.
(In reply to comment #1) > I forgot to mention that I'm using mailnews.sendInBackground = true. I don't > know if it's related or not. Note that sendInBackground is an incomplete feature and does have potential dataloss issues. That said, if this is an issue with it, then its probably an issue with the send later code as well, and if we can get confirmation of the bug it needs fixing before we implement sendInBackground.
Carlo, 1. does this reproduce for sendInBackground =false? 2. what minutes value do you have set for auto save and check for new messages?
FYI. > Bug summary : Drafts not deleted on IMAP after message has been sent Known cases; (a) Auto-save after mail send request(known bug), or mail send while auto-save is in progress(known bug), can produce undeleted draft mail after sucessful mail send. It's because of contention between "draft delete after successful mail send" and "append of draft mail, or delete of previous version, by auto-save" can happen. If this case, "multple draft mails kept" usually doesn't occur. Usually "only single undeleted draft mail". (b) Intentional setting of Sent folder == Drafts folder. This also causes contension of Sent==Drafts between "mail sending" and auto-save easily.
sorry for not answering before: my current configuration: Mozilla/5.0 (Windows; U; Windows NT 6.1; it; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b2 Thunderbird/3.1.7 sendInBackground=true, autosaveinterval=5 (default), message checking interval 1 minute - manually saving the draft and then sending immediately => draft not deleted - manually saving the draft, refreshing the draft folder and then sending immediately => draft deleted - waiting for autosave to occur then sending immediately => draft not deleted - waiting for autosave to occur, refreshing the draft folder and then sending immediately => draft deleted - saving multiple copies of the draft and then sending immediately => last draft not deleted - saving multiple copies of the draft, refreshing the draft folder and then sending immediately => drafts deleted setting sendInBackground=false seems to fix everything
Summary: Drafts not deleted on IMAP after message has been sent → Drafts not deleted on IMAP after message has been sent (with sendInBackground=true)
This is what I have been seeing also (I've been using 1 minute for both). sev=Major, because you can't trust what's in Drafts folder Carlo, great detail, thanks for checking that!
Blocks: sendinbackground
Severity: minor → major
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm not sure if this is the same issue, but when I've been editing a draft for a while I have lots of copies of it (one of the marked as 'unread') in the Deleted folder!
In my environment, the messages show up in the Drafts IMAP folder (through other clients), but are empty in the Thunderbird 10.0.5 Drafts folder. This looks like when messages are deleted in Thunderbird (tagged deleted), but never expunged from the server. Compacting the Drafts folder inside Thunderbird made them disappear from my other IMAP clients.
Blocks: tb-drafts
In my opinion, this bug affects not only sendInBackground = true; I'm using Thunderbird 17.0 with mailnews.sendInBackground = false (default), autosaveinterval=5 (default), message checking interval 10 minutes. The behaviour is like described in Comment 2: - previously-created auto-saved drafts are not automatically deleted by Thunderbird when the final version is sent. - The last auto-created draft, however, is auto-deleted - Compacting the Drafts folder inside Thunderbird made them NOT disappear - Repairing the .msf file does not resolve the problem The only workaround I figured out is to use a local Draft folder.
I am having this problem on Thunderbird 17.0 in Windows 7 x64. I see the same messages in the Drafts folder via another IMAP client, web-based squirrelmail. I run the server (Dovecot) so if you have questions about that side, I can answer them. I could not compact the Drafts folder in Thunderbird at the time of writing because another operation was in progress. I couldn't tell what that other operation was, but I do see a half-filled progress bar in the status bar. The way the computer is acting, I think it must be downloading a large number of messages and indexing them for search.
Whatever Thunderbird was doing in the background seems to have finished. Compacting didn't change anything, either locally or in the other IMAP client.
This could be related to how long it takes to send the email. My mail server is on my home network. My copy of Thunderbird at home (also 17.0 on Windows 7 x64) does not seem to have this problem - the network connections are local, only going through a dedicated firewall appliance to reach the server. Sending mail is very very fast. The copy of Thunderbird at work is where I have seen the problem. In this case, the traffic travels across the Internet and sending mail takes a few seconds. The mailnews.sendInBackground setting is false in both locations.
(In reply to Carlo Alberto Ferraris from comment #0) > This is true at least when using IMAP, I don't know what happens when using > local folders (I only use IMAP mailboxes). Same or similar cause of bug 530528? Read thru also bug 710586 and bug 522336. What is regression window of your problem? Same as bug 530528 comment #7? Or different from bug 530528 comment #7?
Hi, I've been experiencing this for a long time, using plain vanilla IMAP servers (IMAP2002, 2004, uw-imap), both at 100Mbps LAN and 256Kbps WAN connections; now exacerbated with TB17. Right now I've installed Auto Save Drafts Folder, that adds a config option to save those annoying (but useful) auto-save drafts on a different folder, for example a local folder, and leave those intentionally saved drafts on the IMAP folder, so a rush from office to home (or viceversa) can't interrupt an important email (providing that I remember to save as draft...), and auto-saved drafts are kept in local folders, and auto-deleted when mail is sent or canceled. https://github.com/dlech/AutoSaveDraftsFolders/wiki The only drawback is I have to set this up on the 5 computers I use TB on... Regards
I started experiencing this issue since yesterday, on Gmail IMAP...
Is there anything new ? The bug is still present.
If IMAP Drafts only problem, "not deleted draft mail by sendInBackground" is actually "last saved draft mail before send request with sendInBackground=true"? "not deleted draft mail by sendInBackground" is "saved draft mail by auto-save after send request", isn't it? 1. last draft save to IMAP completes. UID=1001 2. Send is requested with sendInBackground=true. UID of last draft mail==1001 for send process. Time required to complete "Send mail process" is always greater than ZERO. 3. Auto-save happens while "send process" is executing mail sending. UID=1002. 4. Upon actual mail sending, UID=1001 is deleted. UID=1002 is not deleted because unknown draft. If this kind of problem, NSPR log with following option may help your problem analysis. NSPR_LOG_MODULES=timestamp,imap:5,MsgCopyService:5 "write to Drafts folder", "write to Outbox folder" is logged by MsgCopyService:5. "append to IMAP Drafts folder", "Store flag \Deleted at IMAP Drafts folder" is logged by imap:5, and UID of draft ail can be known. Because "Order Received" column value==UID of mail if IMAP, you can know UID of draft ail by showing "Order Received" column. (In reply to Sergio R. Caprile from comment #19) > Right now I've installed Auto Save Drafts Folder, that adds a config option > to save those annoying (but useful) auto-save drafts on a different folder, > (snip) > and auto-saved drafts are kept in local folders, and auto-deleted > when mail is sent or canceled. If sendInBackground=true, "Delete of last saved draft mail" looks executed upon actual mail send. If IMAP Drafts only problem, similar problem to bug 530528(fixed by Tb 26)? That bug is; Upon draft save, Send Later, Tb fails to write "pointer to Replied mail"(MessageKey==UID of mail if IMAP) to Drafts.msf or Unsent Messages.msf. So, Tb can't mark the Replied mail as "Replied" when mail is actually sent. If this is applicable to "pointer to last saved draft mail" of "mail sent with sendInBackground=true", similar problem to bug 530528 may occur. To all problem reportes: Bug 530528 will be fixed by Tb 26. Do you see your problem with latest trunk nightly? > http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ > as of today, Tb 30
(In reply to WADA from comment #22) > Do you see your problem with latest trunk nightly? Yes. Many messages in my Drafts folder have been sent a while ago. When I mark them as deleted, they do not go away - even after I select "Compact" for the Drafts folder. I'm using IMAP with my Google Aps account. Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Thunderbird/30.0a1
(In reply to Peter Lairo from comment #23) > Many messages in my Drafts folder have been sent a while ago. When I > mark them as deleted, they do not go away - even after I select "Compact" > for the Drafts folder. I'm using IMAP with my Google Aps account. I experience the same problem: drafted messages are not deleted when I send them. I don't think these is a contention between autosave (which is set to 5 mins) and sending itself (takes few seconds). I also have the same problem with removing the message from Drafts: they reappear again. TB 17.0.11, Gmail IMAP.
Hi, I have this bug since I am using IMAP. Nothing changed or repaired until now. I am using TB version 31.7.0 right now. In our office 7 computers are accessing the same IMAP e-mail...maybe that is the reason of not deleting some of the sent e-mails? Sync or draft refreshing problem? For example on one computer TB deletes draft and on the other PC the delete is not synced and the draft e-mail is copied again on the first computer...maybe? I cannot repeat the problem when I am testing it. Daily I send up to 80 e-mails and about 2 e-mails are left in draft in the end work. Local draft folder is not an option for me, because sometimes I want my coworker to finish the e-mail. TB 31.7.0 IMAP (not Gmail)
This is still happening with the last Thunderbird 59. Very annoying that although you have your draft folder empty in Thunderbird, the emails are still shown on Outlook on other machines.

When I switched completely to Thunderbird on macOS in 2014 I configured all accounts to automatically save a draft in the local draft folder while composing an email. A few years ago I switched all accounts from POP3 to IMAP, starting all new accounts in TB. No problems whatsoever.

Now, since one of the latest updates in TB 60 this rather annoying bug has come up. Every five minutes a new draft version is saved in the local draft folder, and when I have sent an email I kept composing for a while I have to delete all these useless drafts.

Could someone please look into this? Could you please raise the priority so that this issue can be resolved soon?

Is there a way to switch saving drafts off altogether? The interface only seems to give me the opportunity to select the folder to save to.

Thx!

Now that Google is forcing users to switch from POP to IMAP, many more of us are encountering this bug. It's really frustrating to have every single email written in Thunderbird create a long series of draft messages that pollute the Gmail inbox. This happens even when the Thunderbird account settings are configured to make use of the Drafts folder on the IMAP server. For normal day-to-day usage there is no reason for auto-save to create more than one draft, and no reason for the draft to remain after the mail has been sent. Please boost the priority of this bug. Thunderbird 68.6.0 (64-bit) on macOS 10.14.6.

My sendInBackground=false and I still get this issue.

Maybe the platform label "Windows XP" should be removed too, to get more attention.

8 years later in July 2020 and this is still an unresolved major bug ... could someone please look into this? I'm happy to donate! Nowadays as most people are (finally) moving away from pop3 to IMAP this does quite a bit of damage.

  • as all these drafts eat space and TB includes all attachments too, so some 5-10MB attachment (which in 2020 is no longer a problem, nor uncommon) adds to hundreds of MB stored because TB makes tens of copies for emails that take a long time to write (depending on the auto-save timer too!). I ran into quota problems several times ...

  • the global search indexer is affected too, which affects search results, as well as extensions relying on the search indexer, e.g. the VERY popular "Thunderbird Conversations" which shows mostly draft emails in the list of emails that make up an email chain. This makes it hard to navigate and likely to miss actual emails.

So it's not just annoying any more ...

OS: Windows XP → All
Summary: Drafts not deleted on IMAP after message has been sent (with sendInBackground=true) → Drafts not deleted on IMAP after message has been sent (perhaps worse with sendInBackground=true)

See also Bug 460085, maybe they are the same problem. I encountered this now with an enterprise mail provider 163.com.

Attached file imap log —

Log process: start TB, write a new mail, check to see draft been saved, then send. Draft is not deleted.

A workaround that has worked for me so far, and might give some insight on the location of the bug, is the following:

  • Auto-generated drafts are kept on a local folder by using "Auto Save Drafts Folders" (by dlech). No problem here.
  • If the mail has been manually saved as draft, don't keep editing it. Close that mail.
  • Later, whether you need to keep editing or just send: open the drafts folder, select that mail, and click on 'Edit' for that mail. Then save again or send. If you save, close.

This is a bit tedious but keeps one single draft that gets deleted when sending.

My impression just recently (both on Thunderbird 91.2 on macOS and on Thunderbird 78.13 on Linux) was that when the "Drafts" and "Templates" folder is set to the same IMAP-Folder, this problem occurs. I did that to avoid accumulating more than necessary unnecessary folders that I never use. Now I set again two different folders (in all identities for this account), and apparently now the drafts are auto-deleted again.

(In reply to emmy.graugans from comment #35)
Nope, different folders here (both on IMAP server) and draft leftovers... in Linux and W7.

(In reply to Sergio R. Caprile from comment #34)

A workaround that has worked for me so far, and might give some insight on the location of the bug, is the following:

  • Auto-generated drafts are kept on a local folder by using "Auto Save Drafts Folders" (by dlech). No problem here.

"Auto Save Drafts Folders" (by dlech) is no longer compatible, so this has been driving me nuts again for a long time now.
Oh, and sometimes valid drafts get deleted, so writing a piece, saving as a draft, closing, and thinking on resuming later on the same or another machine, is a risky business.

See Also: → 1874275

This has been a "problem" for years for me. Sometimes I have to go into the drafts folders and manually delete all the unintended ones.
Would it be possible to just get a prompt after sending the email to delete all the drafts that were saved from the same email?

Yes, this bug has been annoying me for years as well. It creates needless work for me by forcing me to manually delete all old drafts.

I find it quite awesome that this bug is unsolved since 15 years. Anyway: Happened with my Thunderbird (current 115.15.0) a few times recently that a mail which I just sent and which is saved in Sent folder still is saved in drafts folder. So I searched and came here.
I guess only this https://support.mozilla.org/bm/questions/1419945 is the problem – but it's not the solution.

One common thing when it happened is that my email had one or more big attachments. Like this, the saving process takes longer and there is a much greater chance that I will click "Send" right while the draft is auto-saved and then the draft will remain even though the email has been sent.

It is quite irritating and you wonder full of doubt whether something went wrong with the sending and whether you should resend the email, so I plea for this to be solved.

I've learned to live with it, w-sky, it is now "a feature", along with 'start the week on' randomly going back to Monday on updates.
Yet there's a complimentary feature that we users need to be aware, and is that if you happen to have more than one draft message because, let's say, you are writing something to be sent later, or you just fancy having a draft message in your draft messages folder, the nice process of taking care of draft messages will randomly erase this other message for you.
So, be warned of this great feature, and save your messages somewhere else, because be it an auto draft or a manually saved draft, it will be erased to leave room for the other unnecessary auto drafts that you won't need after sending.
To sum up: several copies of the same message that you've just sent, or, if you want to have drafts of your next message, don't try to write another message. And hope it is not erased for no reason.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: