215044 - Offline-composed messages are discarded if move to IMAP 'sent' folder fails

Status: RESOLVED DUPLICATE of bug 28211

(MailNews Core :: Networking: SMTP, defect)

Description

[Branen Salmon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla Thunderbird 0.1 (20030723) using 16-Jun-2003 offline extension

When a message that was composed offline ("Send Later") is sent, but cannot be
copied to an IMAP-based "sent mail" folder, the sent message is discarded. 
Thunderbird does provide an error dialog, but provides no option to save the
sent message in the local "sent mail" folder.

Reproducible: Always

Steps to Reproduce:
1.  Start Thunderbird with the offline extension.  Make sure you are using an
account set to automatically save copies of sent mail in an IMAP-hosted folder.
2.  Take Thunderbird offline.
3.  Compose a message.  Click "Send Later."
4.  Simulate a temporarily unreachable IMAP server by setting the IMAP server
port to something invalid.
5.  Take Thunderbird online, and choose to send queued messages now.
6.  Notice two dialogs:
  a.  Some sort of connection failure alert, eg "Could not connect to mailserver
imap.foo.com; the connection was refused."
  b.  The following "Send Message Error":  "The message was sent successfully,
but could not be copied to your Sent folder.  Please verify that your Mail &
Newsgroups account settings are correct and try again."

Actual Results:  
The message, though sent, is nowhere to be found in any local or IMAP folders.

Expected Results:  
Rather than just throwing up its hands ("The message was sent, but could not be
copied"), Thunderbird should save a copy of sent mail in the local "Sent"
folder, which the user can then copy to the IMAP server or delete at user's
convenience.

Comment 1

[Jan Kozanek]

See also 224670 for additional comments please.

Comment 2

[Scott MacGregor]

*** Bug 224670 has been marked as a duplicate of this bug. ***

Comment 3

[Will Budreau]

Special case of bug 254178

Comment 4

[Nikolay Shopik]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080828032200 Shredder/3.0b1pre

Comment 5

[Wayne Mery (:wsmwk)]

(In reply to comment #4)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre)
> Gecko/20080828032200 Shredder/3.0b1pre

Nikolay does your comment mean "yes I see this?"

Comment 6

[Nikolay Shopik]

Exactly Wayne, same as here
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081114 Shredder/3.0b1pre

Comment 7

[Wayne Mery (:wsmwk)]

not sure what this would be a dupe of - I'm stopping at http://tinyurl.com/5o8hc9 for now. Bug 28211 perhaps related.

Comment 8

[Nikolay Shopik]

I agree bug 28211 looks very related but in this case user sends from offline mode but in same time they are maybe same issue in code.

Comment 9

[Mark Banner (:standard8)]

Bug 28211 and this are very much related, though may have different solutions. Adding link for now, and putting this one in the correct place.

Comment 10

[Wayne Mery (:wsmwk)]

a decision on how to address this seems wise given the dataloss potential increased emphasis on offline workflow in TB3, eg bug 440794. so suggest blocking

Comment 11

[Mark Banner (:standard8)]

Yep, I need to fix this as the offline case is actually worse than bug 28211 (you can't even save as draft).

Comment 12

[Mark Banner (:standard8)]

I'm going to be fixing this in bug 28211, so removing from blocking list as that one is now blocking.

Comment 13

[Mark Banner (:standard8)]

Attachment: WIP

Having originally thought of fixing this on bug 28211, the discussion on there leads to fixing it for sending in background/later being easier than for fixing it for everything.

This is a very draft, significantly broken patch. What it does is this:

- Don't delete message from outbox on send complete, wait until copy completed as well.
- When send is successful, set the property "messageSentFlag" to 1 on the message header in the outbox.
- If a copy fails, retry it automatically.
- If the copy still fails, abort and wait.
- Next time we send unsent messages we'll check the flag, and if it is set then we'll just retry doing the fcc rather than send + fcc.

The only problem with this last step is that we have to redo the temp message file in nsMsgSendLater to ensure we get everything set up correctly (and remove the unnecessary headers) for the fcc, but I don't think that is a major issue, especially as we'll be doing this bit in the background.

Comment 14

[Wayne Mery (:wsmwk)]

similar?  Bug 397910 Message Drafts [Not Saved When] Composed Offline not kept after going online

Comment 15

[Rolf Leggewie]

There are certainly some relations to bug 397910, but I'm not convinced we are looking at the same issue.  The other report seems to highlight that TB simply forgets to save the draft after going online.  This bug is about TB trying to save the sent message.  When that fails, TB just looses the message.

Comment 16

[Jens Müller (:tessarakt)]

Target milestone? wanted/blocking TB3?

Comment 17

[Mark Banner (:standard8)]

(In reply to comment #16)
> Target milestone? wanted/blocking TB3?

This won't be happening in TB 3 unless someone comes up with specific code. I have some ideas for how to fix it (comment 13) but that won't happen until after TB 3.

Comment 18

[WADA:World Anti-bad-Duping Agency]

Phenomena observed with Tb 3.0xpre in other bugs.
> with Gecko/20090619 Shredder/3.0b3pre : Bug 397910 comment #1
> with Gecko/20091112 Shredder/3.0pre   : Bug 528669 comment #1.

Comment 19

[Mark Banner (:standard8)]

(In reply to comment #18)
> Phenomena observed with Tb 3.0xpre in other bugs.
> > with Gecko/20090619 Shredder/3.0b3pre : Bug 397910 comment #1
> > with Gecko/20091112 Shredder/3.0pre   : Bug 528669 comment #1.

Sorry, but they are nothing to do with this. This bug is to do when you've been offline, sent an email which goes into the local outbox, then go back online and then try to send it. At which stage, there sometimes is an error saving it to the sent folder, and if there is then you'll loose the copy of the sent message.

Those two bugs are both about saving messages in IMAP folders whilst offline, and then coming back online and them getting lost.

Comment 20

[David :Bienvenu]

Hmm, an other possibility would be to simply do the copy to the fcc folder as an offline imap operation, and play it back in the background. As an offline imap operation, we wouldn't have to worry about the dataloss, or scheduling a replay. Everything should just happen automatically.

Comment 21

[Jonathan Kamens]

Wish somebody would fix this, it's a DATA LOSS bug that has been around for 12 years. It doesn't just affect offline users, either. It also affects people who use add-ons like BlunderDelay and Send Later.

Comment 22

[David M]

Just discovered this bug. Didn't like loosing my work! Seems like a bit long for something that is this important.

Comment 23

[Jorg K (CEST = GMT+2)]

Should be fixed by bug 28211/bug 1366591. If not, please file a new bug.