User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2b3) Gecko/20091115 Firefox/3.6b3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:22.214.171.124pre) Gecko/20090915 Thunderbird/3.0b4 If I compose a message, at some point close the main window and then keep on writing and sending the message, it will send ok but will says that it was unable to be copied to the sent folder. Reproducible: Always Steps to Reproduce: 1. Create new message 2. Close main window 3. Send message Actual Results: Message will send, copying to "sent"-folder however fails. Dialog pops up, says: "Nachricht konnte nicht in den Ordner "Gesendet" kopiert werden. Nochmals versuchen?" (OK, Cancel) roughly translates as: "Message could not be copied to sent folder. Try again?" Hitting OK yields the same result. Hitting Cancel yields: "The message has been sent but copying to the sent folder failed. Do you want to return to the draft-window?" Checking the sent-folder however, I find that the message is there! Expected Results: No error should appear, as the message seems to be copied OK. Win7Pro 64bit. Google Mail Account (German), STMP-server: smtp.googlemail.com
This bug might be generalized to include other issues that occur when the main mail window is closed in Thunderbird. For example, I am unable to save a draft mail message to an IMAP Drafts folder when the main window is closed but the compose window is open. This produces the following mismatched error: "There was an error copying the message to the Sent folder. Retry?" Also, bringing up the main mail window again (CTRL+1 on Windows), I'm unable to get any new mail for the account or view any non-cached messages. I need to quit and restart TB for things to return to normal. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:126.96.36.199) Gecko/20091122 Shredder/3.0.1pre
I just reproduced some of the behaviour reported by Brett Leber: the message I sent which TB reported as not able to save does not show up until I close down and restart TB.
I've seen this error too, at various times, mostly in the guise reported by Brett (save draft apparently not working, but then did actually save), but occasionally as stated in comment #0. Reproduced with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:188.8.131.52) Gecko/20091204 Lightning/1.0pre Thunderbird/3.0, as well as (IIRC) with betas 2 and 4, so this is not a Windows 7-specific bug, nor GMail-specific either, as I use a variety of different SMTP servers.
can you refine the steps (or variations) that cause this and determine if this is a duplicate?
Same problem, same steps. Using Windows XP SP3 and TB3. If I try to save message like a file (after step 3 described by Philipp Krüger), it saves wrong, without headers (only body, including the subject in the body). Is possible avoid Main window close if there are another thunderbird window opened (not another Main, but compose, address book, read message windows)?
Are you guys using extensions ? Can you try to reproduce when Thunderbird is started in -safe-mode (http://kb.mozillazine.org/Safe_mode) ?
(In reply to comment #7) Reproduced in Safe Mode also. (In reply to comment #5) > can you refine the steps (or variations) that cause this and determine if this > is a duplicate? I'll work on that, and try to narrow it down.
[may be instructive to know if Mac sees some/all of what's reported in this bug] I saw this today (not for the first time). Closing 3pane is not something one ordinarily does, and so these steps are an edge case. But, probably these should either be fixed or the 3pane should not be closable unless all other windows are closed. Anyway, dug further. Finding bad things (my environment is imap, vista): * open the 3pane back up and you see permanent busy cursor, and tab throbber * under no circumstances would new compose windows be able to save drafts or sent folder * I stopped getting new mail There may be related bugs. (Perhaps even an invalid or wonfix) But for now, confirming. If someone finds a duplicate, please do the "right thing". xref: Bug 28211 - On Send, fail to copy to Sent folder should let user retry, or offer "plan B"
Status: UNCONFIRMED → NEW
Component: General → Mail Window Front End
Ever confirmed: true
QA Contact: general → front-end
Summary: With main window closed, sent email cannot be copied to "sent"-folder → With main window/3-pane closed, sent email cannot be copied to "sent"-folder and drafts cannot be saved - "There was an error copying the message to the Sent folder. Retry?"
Got this problem on all my clients computers running with imap account, WinXP sp3 + Thunderbird 3 , pretty anoying , no problem on clients where there's only pop3 accounts configurated.
Just bumped into this one myself, except in my case, the message was (not* saved to the Sent folder, although it was sent - and I actually ended up trying to send multiple times, and so ended up sending multiple copies of the same message. Reopening the main window did not remedy the problem either. Windows XP Pro (32-bit) sp3, TB 3.0.1, and yes it was an IMAP account.
Same issue encountered here with IMAP accounts. This is a show stopper for me. At home we have the main window open and closed all the time while individual emails remain half-written. In these situations you tend to lost your emails in progress since as soon as that window is closed you can no longer save them to drafts.
Well, you can copy-paste them into text files, etc, but no, that's not a very good 'solution', even as a workaround...
(In reply to comment #7) > Are you guys using extensions ? Can you try to reproduce when Thunderbird is > started in -safe-mode (http://kb.mozillazine.org/Safe_mode) ? I recently downloaded the Daily build as suggested on the How To Report A Bug page. I installed on a new PC, under a new profile and recreated this issue. All you need to do is configure an IMAP account, compose a new email, close the main TB/Shredder window and then click Save on your compose window. It will fail to save to the IMAP folder. I was not using a Gmail IMAP account, just one run by my ISP. I think they use courier-new if that makes any difference.
I wonder if we're tearing down some important information when the 3-pane window is closed, even though the compose window is open. Does the same thing happen when it's a stand-alone msg window open (i.e., a message viewed in a single window).
If you open a message in a new window and close the 3-pane, then re-open the 3-pane (e.g. by relaunching Thunderbird.exe), messages send and receive as normal.
(In reply to comment #17) > If you open a message in a new window and close the 3-pane, then re-open the > 3-pane (e.g. by relaunching Thunderbird.exe), messages send and receive as > normal. But what if you just try to send from the stand-alone message window without a 3-pane window open? That works for me here.
Yes, for me too. So perhaps the compose window doesn't retain the necessary state, but evidently message windows and the 3-pane do.
From what I can tell, we don't have clear steps that a developer could use to reproduce. Until we get those, this can't block.
Flags: blocking-thunderbird3.1? → blocking-thunderbird3.1-
blocking-thunderbird3.1: --- → -
The opening comment by Phillip stated them, but I'll restate them with a little more specificity: 1. Open TB. 2. Begin composing a new message *in a separate window*, *using an IMAP account* - do not save or send it yet. 3. Close all other TB windows (especially the main 3 pane window). 4. Try to send the message. 5. The message sends, but gives an error that it can't save it to the Sent folder. 6. You cannot save the message as a draft, and re-opening the 3 pane window does not resolve the problem. 7. The problem persists, even with newly composed messages, until you restart TB.
(In reply to comment #20) > From what I can tell, we don't have clear steps that a developer could use to > reproduce. Until we get those, this can't block. actually the steps are quite clear - it's just that a state has been found where it doesn't fail - standalone window open - which I can also confirm with Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2pre) Gecko/20100121 Lanikai/3.1b1pre
additionally, other bad things happen. Examples (once you reopen a 3-pane window) tab throbber stays busy, can't get new mail, clicking folder doesn't take you to last accessed message, ...
This has caught me out many times. The message being replied to is in a tab in the main window, and at a glance just looks like a single e-mail (in the style of TB2) so it is far too easily closed as a reflex action. I have sent items copied to an IMAP folder rather than a local folder, if that makes a difference. Once the error happens, there seems to be no way to reconnect the compose window to the main window; the new e-mail window has to be closed and discarded completely (copy/paste is required to save its contents if you need a copy of the message). I have also seen this on auto-save when taking a while to write an e-mail. I have an IMAP drafts folder, again, in case that makes a difference.
Thanks for clearing up the details, folks. Marking as blocking and aiming at RC1.
blocking-thunderbird3.1: - → rc1+
Not a workaround, but at least a way to scavenge your sent message the next time: Set TB to use a drafts folder under "local folders". Then, if the problem occurs, try to answer the dialogs correctly (-> return to message compose window!), and you can then save the message as a draft. (So, obviously, its the IMAP connection that gets in a zombie state.)
Since moving to TB3 I always get this problem, it's highly annoying... May I ask in which version this bug is planned to be correct ? Anyway, thanks a lot for all development work :-)
Sorry I forgot to send some more details : My version : Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-CH; rv:184.108.40.206) Gecko/20100111 Thunderbird/3.0.1 Happens : each time "main window" is closed, and if "main window" is opened again, it shows "loading" animation forever Once the main window is closed, impossible to : * save drafts * save sent mails (possible to send, but cannot save afterwards) * get new mails * open any folder (except local ones) Hope it helps (even if everyone seems to have explained problem clearly...)
This bug might somehow relate to bug #548070 (occurring when replying to an eml file).
Assignee: nobody → bienvenu
I think this has to do with changes made to avoid running imap urls once the shutdown process has started. We treat closing the three pane window as shutdown starting, because the compose window doesn't register an nsIMsgWindow with the mail session, so it doesn't get counted. We could make the compose window register with the mail session, and the address book, or we could not shutdown if there are any app windows open. The latter would involve using the window mediator to find windows of various "mail" types.
(In reply to comment #31) > We could make the compose > window register with the mail session, and the address book IIRC this was the behaviour in TB 2, if you closed main window with open messages you could continue working or you could reopen main window. Only closing the last window was meaning "shutdown". I think it's easy, simple and understandable by all users. > or we could not > shutdown if there are any app windows open. The latter would involve using the > window mediator to find windows of various "mail" types. This could be a solution, but the first one seems easier, lighter and less intrusive for the user. With this solution, the user could say "Why should I leave this window open". And it makes more "annoying popups" with yes/no questions... Personally I think the first one is a lot better and has no disadvantages. And TB 2 was working like that and nobody never complained (I myself always worked like that without any surprise or problem)
I'm sorry, when I say "shutting down", I'm referring to some internal state, not something the user actually sees. The fix for this should be invisible to the user, other than that the bug is fixed.
This should the easily reproducible cases of this bug. I think you can still get into trouble if you close all but the address book window, and then open a 3-pane or compose window from there, but this is by far the more common case. I'll try to fix that next..
Attachment #428958 - Flags: review?(bwinton)
since this bug involves imap, we can't use a mozmill test.
oh, I should say, this bug won't occur on the mac, or w/ SeaMonkey.
this fixes the address book case. There are several other window types, but none of them allow you to get back to the three pane ui, so they're less important as far as this bug is concerned.
Attachment #428970 - Flags: review?(bwinton)
(In reply to comment #37) > There are several other window types, but none of them allow you to get > back to the three pane ui, so they're less important as far as this bug is > concerned. Not even by re-running Thunderbird.exe to launch a new window?
you can still get into trouble w/ those window types, but it's less likely, which is why I said they're less important.
Whiteboard: [gs] → [gs][has patch for review bwinton]
Comment on attachment 428958 [details] [diff] [review] proposed fix It fixes the bug, and understand why, and while I'ld like to see some automated tests, I understand why we don't have them. So, given all that, r=me. Later, Blake.
Attachment #428958 - Flags: review?(bwinton) → review+
Comment on attachment 428970 [details] [diff] [review] address book part of fix Ditto this one. Thanks, Blake.
Attachment #428970 - Flags: review?(bwinton) → review+
fixed on trunk. I think this would be a candidate for a 3.0x release, if we really are getting a lot of gs complaints.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 3.1b2
Attachment #428958 - Flags: approval-thunderbird3.0.4?
Comment on attachment 428970 [details] [diff] [review] address book part of fix probably less important than the other patch for 3.0x - and both need a little baking.
Attachment #428970 - Flags: approval-thunderbird3.0.4?
(In reply to comment #22) > (In reply to comment #20) >> From what I can tell, we don't have clear steps that a developer could use to >> reproduce. Until we get those, this can't block. > actually the steps are quite clear - it's just that a state has been found > where it doesn't fail - standalone window open What do you mean by 'standalone window'?
I can confirm that the issues I had are fixed in /nightly/2010-03-05-03-comm-central-trunk/thunderbird-3.2a1pre.en-US.win32.zip How are the chances the bug will be fixed in 3.0.x?
the standalone message window - a window that displays a single message, with no message or folder list. I'd say the chances are reasonably good that this fix will land in 3.0.x
Cool... as long as it at least makes it into 3.1, I'll be happy... this just bit me again...
Attachment #428958 - Flags: approval-thunderbird3.0.4? → approval-thunderbird3.0.4+
Attachment #428970 - Flags: approval-thunderbird3.0.4? → approval-thunderbird3.0.4+
THANKS for fixing this!
Just updated to 3.04 and I can confirm this is now fixed. Thanks /very/ much!
This bug continues with version 9.0.1. Had been occurring in v. 8.0 and thought maybe the upgrade might fix it, but it keeps happening again and again. I have Windows Vista, working with a gmail.com email account. After a few minutes of typing an email, the error message "There was an error saving the message to drafts. Retry?" pops up again and again, about once every minute or two. It is quite annoying!
You need to log in before you can comment on or make changes to this bug.