257735 - Drafts wrongly saved to sent folder after failing and retrying (common issue of Drafts/Templates/Outbox==Unsent Messages)

Status: VERIFIED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Dustin Parr]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
Build Identifier: Mozilla Thunderbird version 0.7+ (20040831) (official zip build)

If the saving of a draft fails, you are given the option to retry.  However, the
dialog says "There was an error copying the message to the Sent folder. Retry?".
 Obviously it should say to the Draft folder, but no big deal.  Unfortunately,
it actually DOES copy it to the Sent folder.

Reproducible: Always
Steps to Reproduce:
1. Attempt to save a draft.
2. Have the saving fail for some reason (My personal favorite: disable the wlan
connection temporarily)
3. Retry the save using the dialog.

Actual Results:  
The draft was saved, but to the sent folder instead of the draft folder.

Expected Results:  
The draft should have been saved into the draft folder as it does when it
correctly saves it the first time.

This happened using a branch zip build of thunderbird from (20040831) on both
WinXP Pro and Home.  It was an IMAP account server which had both the Sent and
Draft folders previously created (and working)

Comment 1

[James Davis]

I can confirm this on Linux using 20040901. You may have to alter your
configuration so that the Drafts folder is inaccessible yet the Sent Mail folder
is. I used a Drafts folder on an IMAP server and a local Sent Mail folder and
then  brought the network interface down. The bug could then be replicated
exactly. I suggest this be fixed before the next release.

Comment 2

[Scott MacGregor]

James, please don't plus bugs for the aviary releases. the product release teams
are the only folks that should be doing this. Users who are concerned can
nominate a bug. You'll lose your bugzilla privelegs if you keep plussing bugs
like this :) thanks.

this is not a 1.0 stopper.

Comment 3

[Marc Laporte]

I confirm this bug on T-bird .8 for WinXP

This is very annoying because one can believe the message was sent.

Comment 4

[Steffen Wilberg]

When this happens, I get asked twice if I want to retry copying the message to
the Sent folder. That is, after I click Retry, another dialog pops up, asking
the same question. If I click Retry again, I end up with two copies of the
message in the Sent folder, although the message hasn't been sent at all.

Comment 5

[Chris Beard]

-'d for 1.8b4 per mscott

Comment 6

[Scott MacGregor]

No one jumped in on this in time for thunderbird 2.

Comment 9

[Wayne Mery (:wsmwk)]

is an imap log of any help?

I encountered this (or bug 354064 - first time obviously). 
I don't know yet if the message was sent.
I ended up with one message in drafts and two in my sent folder.

Comment 10

[Patrick]

This just happened here in 2.0.0.17 (more than four years after it has been reported, by the way). To me it seems like somebody copy & pasted some code from the Save-to-Sent-retry-handling routine into the Save-to-Drafts-retry-handling routine and forgot to actually change 'Sent' to 'Drafts'...

It's a quite irritating bug, because users who don't have access to their SMTP server log don't even know if the mail has been sent out.

Comment 11

[Magnus Melin [:mkmelin]]

Wouldn't block for this; blocking‑thunderbird3-

Comment 15

[Rolf Leggewie]

still present in 3.0.4 as shipped currently in lucid

Comment 16

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
> To me it seems like somebody copy & pasted some code
> from the Save-to-Sent-retry-handling routine into the
> Save-to-Drafts-retry-handling routine and forgot to actually change 'Sent' to
> 'Drafts'...

Oh, it was not "fall back to Sent".
Putting some bugs in dependency tree to close many reports for rediscovery of this bug's phenomenon/problem.

Comment 17

[Patrick]

(In reply to comment #16)
> Oh, it was not "fall back to Sent".
> Putting some bugs in dependency tree to close many reports for rediscovery of
> this bug's phenomenon/problem.

So, you're saying, when a message can't be saved to the Drafts folder for some reason, the fallback is, to save it to the Sent folder??
Why would anyone look for their drafts in the Sent folder? I mean, it's better than throwing the message away, which could have taken hours to write. But really - the sent folder? This just makes you think, you accidentally clicked the 'Send' button, instead of the 'Save' button - and this may cause quite some confusion!
The fallback should be, to save it in a local Drafts folder. Or save it to some text file, or something - but not in a "random" other folder!

Comment 18

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #17)
> So, you're saying, when a message can't be saved to the Drafts folder for some
> reason, the fallback is, to save it to the Sent folder??

No.
While testing "save draft to Drafts failure" cases for other bugs(many were dup of this bug), I saw phenomenon of "draft mail was saved in a folder defined as folder to save sent mail copy at Copies&Folders", for one of Identities associated to account to which identity used as From: of mail is associated.
If retry(attempt to save draft mail in Sent) failed too, error message/dialog said "Sent folder" or "Send failed".
So, I thought(misunderstood) it was a kind of fall back. It's not useful if local folder, but it's reasonable in some situations because "draft is saved in Sent" is far better than "silent loss of draft", if error on IMAP Drafts and fall back to IMAP Sent.

> The fallback should be, to save it in a local Drafts folder.
> Or save it to some text file, or something - but not in a "random" other folder!

You are right.
If long IMAP server down, automatic fall back to IMAP folder is impossible. 
Bug 28211 is such request for Sent folder.
> Bug 28211 On Send, fail to copy to Sent folder should let user retry, or offer "plan B"

Comment 19

[Wayne Mery (:wsmwk)]

thanks wada. 

my request isn't well articulated, but suggest this is wanted-thunderbird and should be easy to fix

Comment 20

[Nelson Bolyard (seldom reads bugmail)]

This bug needs to age some more.  
6 years isn't long enough for a bug in core functionality.

Comment 21

[WADA:World Anti-bad-Duping Agency]

Setting dup'ed bugs in dependency tree, for ease of viewing aging history.

Comment 23

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
> it seems like somebody copy & pasted some code from the Save-to-Sent-retry-handling routine
> into the Save-to-Drafts-retry-handling routine
> and forgot to actually change 'Sent' to 'Drafts'...

It looks same on Save-to-Outbox(Unsent Messages)-retry-handling routine.
See bug 619884 comment #6, please.

Comment 28

[David :Bienvenu]

Attachment: untested fix

this is where we're doing the wrong thing, with a potential fix. We should add a new string for saving to non-sent folders as well. Not sure how we can add a test for this...

Comment 29

[David :Bienvenu]

Attachment: fix with string change

untested but with different string for non-sent errors

Comment 30

[David :Bienvenu]

Attachment: proposed fix

This makes us use the folder name as remembered in MimeDoFcc in the error saving message, and gets rid of a now unused method (nsMsgAskBooleanQuestionByID) and gets rid of another ID-style properties string.

Comment 31

[[e-mail]]

What happens if you send a message, and the copy to Sent succeeds, but the extra copy to the user-selected Fcc folder fails?

Comment 32

[David :Bienvenu]

(In reply to comment #31)
> What happens if you send a message, and the copy to Sent succeeds, but the
> extra copy to the user-selected Fcc folder fails?

It should be fine - nsMsgComposeAndSend::NotifyListenerOnStopCopy gets called at the end of the first fcc, we then initiate the second fcc by calling MimeDoFcc again, which remembers the new folder name, etc.

Comment 33

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #30)
> proposed fix

Can your patch be easily enhanced for "plan B"(bug 28211, bug 354064) in these bugs by logic like next?
> 4185 nsMsgAskBooleanQuestionByString(prompt, msg.get(), &retry, nsnull);
> 4186 if (retry)
> 4187 {
> 4188  mSendProgress = nsnull; // this was cancelled, so we need to clear it.
> 4189  return SendToMagicFolder(m_deliver_mode);
> 4190 }
       else if (Plan_B)
       {
        mSendProgress = nsnull; // this was cancelled, so we need to clear it.
        Show folder selection panel;
        if (!cancel) switch to selected folder, then proceed; 
       }

Comment 35

[David :Bienvenu]

(In reply to comment #33)
> (In reply to comment #30)
> > proposed fix
> 
> Can your patch be easily enhanced for "plan B"(bug 28211, bug 354064) in these
> bugs by logic like next?
The patch doesn't make it easier or harder, though it does show where the code change could go.

Comment 36

[David :Bienvenu]

Comment on attachment 501425 [details] [diff] [review]
proposed fix

Standard8, if you want to steal this review so that the fix makes a2, please feel free.

Comment 37

[David :Bienvenu]

Attachment: fix for 3.1.8

this is a non-string version of the fix for 3.1.8, that just makes sure we don't save the draft in the sent folder, thereby confusing users.

Comment 38

[Mark Banner (:standard8)]

Comment on attachment 501425 [details] [diff] [review]
proposed fix

r=Standard8

Comment 39

[David :Bienvenu]

fixed for 3.3a2 - http://hg.mozilla.org/comm-central/rev/d3121c483250

Comment 40

[Mark Banner (:standard8)]

Checked in the code change only patch for 3.1.8: http://hg.mozilla.org/releases/comm-1.9.2/rev/f33d43fd3fa6

Comment 41

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #39)
> fixed for 3.3a2

VERIFIED with next build on Win-XP.
> Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110115 Thunderbird/3.3a3pre

Local mbox case was resolved as expected.
(1) Edit a draft mail
(2) Rename local unix mbox file for Drafts, Templates, Outbox(Unsent Messages)
    Drafts=>DraftsXXX, Templates=>TemplatesXXX,
    Unsent Messages=>Unsent MessagesXXX
(3) Save As Draft, Save As Template, Send Later
    => "Mbox full" message.
       "File doesn't exist" condition returns -1 to "write open" request,
       and it's interpreted as "file size max exceeded"?
    => "Unable to save ..., retry or cancel" message for each folder.
(3) Rename local unix mbox file for Drafts, Templates, Outbox(Unsent Messages)
    DraftsXXX=>Drafts, TemplatesXXX=>Templates,
    Unsent MessagesXXX=>Unsent Messages
(4) Reply OK(retry) to "Unable to save ..., retry or cancel" message.
    => draft, template, unsent message is successfully saved to
       save target mail folder.

IMAP and "draft folder doesn't exist" case was different.
(1) Drafts folder doesn't exist on IMAP server.
    Rool level "Drafts" of IMAP account is set as draft folder for identity.
    Some other identities uses Draft-1 as draft folder.
    As Gmail IMAP account, [Gmail]/Drafts is also a draft folder.
(2) Compose a mail, Save As Draft
    => "Copying ..." dialog won't stop.
       Creation of rool level Drafts is not requested.
    Cancel reply to dialog => "Save As Draft" does do onthing here after.
    Close compose window => "Save or Quit" dialog => Reply "Save"
    => "Copying ..." dialog won't stop => Cancel reply
    => Copies&Folders setting is automatically changed to "Others: Drafts-1"
       which is existent and used by other identities.
       This seems a kind of fall back mechanism of Drafts/Sent folder.
(3) Stop using Drafts-1 and delete Drafts-1,
    Compose a mail, Save As Draft (Repeat step (2))
    Same as Step (2), and "Other [Gmail]/Drafts" was set by Tb like step (2).
(4) Change back draft to "Drafts folder of: this IMAP account",
    Compose a mail, Save As Draft
    => As Draft still doesn't exist, "Save As Draft" won't complete
    => Cancel => Create "Drafts" folder manually
    => Save As => "Save As" does do nothing like step (2)
    => Close compose window => "Save or Don't save" dialog
    => Reply "Save"
    => Draft is saved to Drafts folder as expected.
Above phenomenon on IMAP Drafts was masked until this bug has been fixed. This is probably a reason why many variants of bug report exist for "IMAP Drafts save failure" case.
I'll check bugs for "IMAP Drafts save failure" case, and will open separate bug for "IMAP Drafts" particular issue(s).

Anyway, this bug has been VERIFIED. Thank a lot to David and Mark for fixing of this long-lived bug.

Comment 43

[reality644-bb]

Please forgive my ignorance of the way this site/ boards probably work, and therefore if this appears a stupid question - I'm a first time user and only found this because I experienced this problem last night and did a web-search.

Gave me a lovely sleepless night because it was a very important email and I couldn't tell whether the incomplete (and subsequently highly modified draft) had actually sent, since in my case the draft actually saved in the Sent folder in my Yahoo webmail (and appeared fully sent), not just in Thunderbird, and I only noticed it had occurred after sending the final version.

In any case, should I understand from the above that this is, in fact, now fixed in the latest Thunderbird release? I can only see a Win XP reference, but I'm running TB 3.1.7 on Mac OS 10.6.6.

TIA.

Comment 45

[Rolf Leggewie]

@reality644-bb: 3.1.7 is definitely not fixed.  

In fact, I just tried 3.1.8 and it's still affected. Although I understood comment 40 to mean that a patch was committed and released for TB 3.1.8. The patch applies almost cleanly to the 3.1.8 sources, too.  Mark, would you be so kind to help me understand where is my misunderstanding?  I'd like to make sure this bug gets fixed in Ubuntu Lucid.

Comment 46

[WADA:World Anti-bad-Duping Agency]

For Tb 3.1.x, see "status-thunderbird3.1:" field of this bug, please. "status-thunderbird3.1: .8-fxed" in the field means "this bug is fixed by Thunderbird 3.1.8".
If this bug is really not resolved by Tb 3.1.8 or newer in your environment, open new bug for it with referring to this bug, please.
If Linux distro specific build, please check documentation about the Tb's build provided by the specific distro.

Comment 47

[Rolf Leggewie]

I cannot imagine that 3.1.8 is fully fixed.  The patch in comment 40 applies cleanly to 3.1.8 sources with one the exception of one hunk.  If the patch had actually been released it should reverse-apply, no?

FWIW, I do think something changed.  I believe the draft is indeed no longer saved to the sent folder.  The warning still talks about the sent folder, though: bug 646421

Comment 48

[Phil Ringnalda (:philor)]

That is exactly what should happen with the 3.1.8 patch - changing the message requires changing localized strings, which we do not do on stable branches, so on 3.1.8 when it fails saving to Drafts, it should say it failed saving to Sent, and should then not actually save in Sent. If the patch in comment 40 (which would be http://hg.mozilla.org/releases/comm-1.9.2/raw-rev/f33d43fd3fa6) still applies except one hunk, that means it doesn't apply at all, since it is one hunk, a single line changed to not actually save in Sent.

Comment 49

[Rolf Leggewie]

My bad.  I was actually looking at the patch in comment 38 and 39, essentially.  I'd just mistakenly assumed I'd gotten it from comment 40.  I guess I understand the situation better now.  Thank you for the fix and thank you for the patient explanations.  I assume the string fix will land in a later release.  Looking forward to it.

Comment 51

[WBT]

Today I sent a message successfully (after a few attempts) and then got the message "Error saving message to Drafts. Retry?" I did retry, and it saved it to the Sent folder, appropriately.  

The mixup between Drafts and Sent seems to be pretty deep!

Comment 52

[WBT]

Attachment: screenshot

I'm attaching a screenshot here related to the last comment about Drafts and Sent getting mixed up.  This has the actual text of the message, not a memory-based paraphrase.  In this screenshot, I'm not sure if the message actually was sent successfully, contrasting the situation in my prior comment.

I'll also bring in Bug 255050 Comment 10, "the reason the messages are wrong is because the code that saves drafts and the code that copies to the sent folder is shared code, not a copy paste error."  That's a little concerning, wondering about the functionality here.

Also, if I'm off target by reopening this bug instead of starting a new one, please feel free to correct me. 

Thanks!

Comment 53

[wolfgang_gensch]

I have same issue lately and would ask for assistance to solve this issue.

Thanks