User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52) Gecko/20070713 Firefox/184.108.40.206
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20070716 Thunderbird/18.104.22.168
Thunderbird cannot save a message as a draft when it is a reply to a message that was forwarded as an attachment. This is worse when auto-save is set, because you get periodic error messages.
Steps to Reproduce:
0. Write a message and verify that you can save it as a draft.
1. In Tools – Options... – Composition – General, set Thunderbird to forward messages as attachments.
2. Forward a test message to yourself.
3. Receive the new message, open it, open the attached copy of the test message, and write a reply to it.
4. Try to save your reply as a draft.
Error message: "Unable to save your message as draft.
Please verify that your Mail & Newsgroups account settings are correct and try again."
Also in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a7pre) Gecko/2007072504 Thunderbird/3.0a1pre
Confirmed on linux/trunk.
Reproduced with Seamonkey 1.1.3(MS Win-XP). Core bug.
*** Bug 413346 has been marked as a duplicate of this bug. ***
This is very annoying, since with auto-save, the error message blocks you from continuing to write (i.e., you *have to* click ok to continue), which gets very annoying.
Also, it attracts the focus to the compose window, even when it is in the background: the error message pops up in front of everything, clicking OK lifts the compose window to focus, so one has to switch to the window one was working with again.
(linux with 22.214.171.124)
My impression is that, if you have autosave and you don't service the dialogue box, Thunderbird eventually locks up (Linux).
*** Bug 439159 has been marked as a duplicate of this bug. ***
This exact problem also occurs if I open a saved .eml file and reply to that message.
version 126.96.36.199 (20080708), and I believe at least one prior version.
*** Bug 391503 has been marked as a duplicate of this bug. ***
I confirm this bug for Thunderbird/3.0b2
It is really annoying.
Confirmed for Thunderbird 3.0.0 on Windows 7 and Thunderbird version 188.8.131.52 (20090812)on Snow Leopard.
Also confirmed as Mark Sapiro stated above
"This exact problem also occurs if I open a saved .eml file and reply to that
We save a lot of email messages for auditing purposes and so this bug is pretty lame. I'd just persuaded everyone to move from Outlook as well.
Bug still exists in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206) Gecko/20100111 Thunderbird/3.0.1
*** Bug 629683 has been marked as a duplicate of this bug. ***
*** Bug 525034 has been marked as a duplicate of this bug. ***
"Assembling mail information..." is also seen in status bar
Don't know if it's only me, but I have one more problem in this situation : I can not paste an image in the reply (instead it show a "broken image" icon)
TB 5 problem. This bug:
- When saving e-mails in *.eml format to the local file system
- re-opening them,
- clicking on reply, adding text
- click on close
- click on "yes safe as draft"
- getting this message:
[Unable to save your message as draft.
Please verify that your Mail & Newsgroups account settings are correct and try again]
existed already in TB3. Work around was to not click on reply but on forward. E-mail could then be saved as a draft.
Now in TB5 even this is not possible any longer. E-Mails saved to the local system (Win 7, 64 Bit) can´t be saved as draft any longer. This is a big problem as many companies safe important e-mails to a digital filing system and can't save them later as draft for further action. Hope there will be a solution soon. Our Company downgraded from TB5 to TB3 again to have a workable workflow.
(In reply to comment #16)
OrchidOne, this is what I reported in Bug 548070 (glad I am not alone ;-)
probably you want to have a look there.
These bugs seem to be somehow related.
However, I get the same behaviour with TB 5 (I can press "save as draft", and I get the same error as in TB 3), tested on WinXP 32, TB 5 release version.
Working with .eml files does not seem to be a recommended option (and might look a bit "oldfashioned"), but also my client here uses .eml files heavily...
I've found that this is a timeout type issues.
When composing an email (reply, forward, edit as new) and I have attachments or images in the email if I take too long (5 minutes) to edit and save or send it will start giving this error.
If I then delete and read the images and attachments it will work just fine again. I think it is loosing the connections to the files that are in the original email message.
This happens more often when I'm editing a template that has already be created (they have attachments and embedded images).
That's interesting - I think you're describing a different way to get the same repeatable error message, and I suppose they could be related. I don't actually know what these objects look like in memory, but maybe the compose/reply window is just incapable of (re-)initiating a connection or using an existing one when it doesn't have one, such as after a timeout or when the reply was launched from a parent who has no reference to the existing connection pool.
I'm sure a timeout is not a required component of this bug, though. This problem has been reproducible for me every time I try to reply to attached mails and .eml files, without waiting for a time-out, whether they are plain text, HTML, have attachments, or no attachments.
Created attachment 584459 [details] [diff] [review]
Basically there were two problems here: currentAccountKey was undefined (set up in another if clause), and in nsMsgSend.cpp we returned a handled error for draft/template saving.
The other changes are whitespaceish, as i got rid of two unncessary if blocks - gCompose or gMsgCompose.compFields really shouldn't be null. If they are you'd want to know.
I'll attach an whitespace patch too for easier review.
Created attachment 584460 [details] [diff] [review]
proposed fix (whitespace changes ignored)
Comment on attachment 584459 [details] [diff] [review]
thx, Magnus - seems to work fine here. And the mozmill test seems OK when run by itself, but when all the compose tests are run, I get several failures in test-forward-headers.js -I'm not sure if your new test is not cleaning up after itself, or what...but I'm going to clear the review request for now, and if you could look into the composition test failure, that would be great.
Created attachment 584602 [details] [diff] [review]
proposed fix v2
This deletes the drafts too, so there's no problem with other tests.
Created attachment 584603 [details] [diff] [review]
proposed fix v2 (whitespace changes ignored)
Comment on attachment 584602 [details] [diff] [review]
proposed fix v2
thx, that makes the tests pass when run in batch.
*** Bug 548070 has been marked as a duplicate of this bug. ***