When I reply to a mail with cyrillic encoding and type some german characters, the cyrillic encoding does not contain these characters. So if I send the message, thunderbird asks to use UTF8 encoding which contains all characters. This is ok. But if I leave the message compose window open and if I have autosave active, after a while thunderbird brings the same popup window asking "Send message in utf8?". This is very irritating because the user believes the message will be sent now. But it will not be sent, it will only be autosaved.

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

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

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

> *** Bug 361172 has been marked as a duplicate of this bug. *** Additions from my bug report (bug 361172): I don't know, if this relates, but: 1. this happens with Tools / Account options / Composing / [ ] Compose in HTML. 2. prompt apper, when new/replied letter contains characters, not presentable in target encoding (Tools / Options / Display / tab Fonts / Encoding / Output encoding). 3. looks like Composer' prompt "Send in UTF-8 / Cancel / Send as-is" correlates with Tools / Options / Composing / tab Main / [x] Automatically save letters each [5] min period. Also, there is second bug, not mentioned/noticed by original reporter: if I press Esc at prompt, then cursor in Composer window is disapper (until I switch from its window to other window and then return back).

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

(In reply to comment #4) > 3. looks like Composer' prompt "Send in UTF-8 / Cancel / Send as-is" The more so, don't know if this correct or not, but red cross is on last "Send as-is" button, not on "Cancel".

Was just about to report the same thing... The problem is that the the same code handles saves and sends but uses the strings "12553", "sendInUTF8" and "sendAnyway" in any case. Two possible sulutions come to my mind. 1) We introduce additional strings "saveInUTF8" and "saveAnyway" with appropriate wording and use these - depending on msgType in these places: http://lxr.mozilla.org/seamonkey/source/mail/components/compose/content/MsgComposeCommands.js#1880 http://lxr.mozilla.org/seamonkey/source/mailnews/compose/resources/content/MsgComposeCommands.js#1849 It needs to be checked that following is called for saves only: http://lxr.mozilla.org/seamonkey/source/mailnews/compose/src/nsMsgPrompts.cpp#184 2) We change the wording of "sendInUTF8" and "sendAnyway" such that it applies to both saves and sends."12553" can stay the way it is, at least for en-US. Any opinions on 1) or 2)? Michael

A prompting like "Treat message as unicode" would be just fine and solve the problem.

My idea -- which is probably harder to implement -- is that saving a Draft *always* use UTF-8 with no prompting at all; then use/check the programmed charset only when actually sending.

The problem is not only about non-unicode. It is also appears with master password warning, when mail is be digitally signed (see duplicate bug https://bugzilla.mozilla.org/show_bug.cgi?id=381348). There is no simple workaroung. The whole Autosave feature is wrong. Autosave should be local operation, it has nothing to do with sending (at least, for POP3 accounts it is always local).

(In reply to comment #9) > My idea -- which is probably harder to implement -- is that saving a Draft > *always* use UTF-8 with no prompting at all; then use/check the programmed > charset only when actually sending. I fully agree here. The user interface is running in UTF-8, so autosaved files should be in UTF-8. Dialog "Send in UTF-8" should only appear when user clicks on Send, otherwise it's highly confusing.

See bug 311821 comment 1 for a workaround. I can add that you can have more fallback charsets - then the value would be e.g. "ISO-8859-2, UTF-8" (for intl.fallbackCharsetList.ISO-8859-1 pref)

BTW would it be overkill to fallback every / some of the charsets to UTF-8 by default ? this should work for save and send operations because these dialogs are equally annoying for the ordinary user and experienced user would have a chance to change it; patch adding additional default prefs would be simple (maybe even fixing the wording) and additional UI for managing this could be taken care in other bug if needed.

Full agreement with comments #9 and #19. Having pop-ups appear at random times (and grab focus from the composition window) is *always* bad. More than once I've happened to press Enter at about the time the dialog appeared, and thought "Oops, what was that dialog I just accidentally confirmed?"

Adding "Send in UTF-8?" in bug summary for ease of search. See Bug 409562 Comment #3.

The "Send in UTF-8" dialog is now proposed to be removed see bug 410333 - this will probably fix this one as well.

We could make the utf-dialog transparent. Wouldn't that be a nice fix?

->WFM. The dialog is now gone, with bug bug 410333 landing.

This is not the same as bug 435163, since it's not only autosave, but also save... And this bugs resolution is not RESOLVED WORKSFORME, but WONTFIX or INVALID, with bug 410333 landing. At first glance I can live with the solution though. Target milestone mozilla1.9 will be TB3?

Yes. I'd consider myself fairly picky with resolutions, but I think wfm is the ok - though there really isn't any good resolution that get resolved this way. If anything, it could be fixed, but but, i try to avoid that for by-way fixes:)

Giving it some more thought, I still think there's something wrong about this solution... For sending I agree it's better for most users to silently send in utf (although I'd rather have Thunderbird to keep prompting me, because most of the time it happens in replies with html and I just strip that out.) But for (auto)saving it would be better to save as is, and not change the encoding. But then again, there's not too much point in saving it as is when you're going to send it in utf anyway.

Looking at the other side, implementing separate logic for saving and sending will be unnecessary bloat. There's nothing wrong on UTF-8 today, and in our university we even suggest to send all emails in UTF-8 which has been proved to work more reliably. It will be some more moths before TB3 gets out, so the acceptance of UTF-8 will be even more wider than today, with legacy charsets starting to slowly go to history.

(In reply to comment #36) Yes, there are always other sides. I thought the logic for save would be based on the same logic as save page in Firefox. But then again: you can't save a page on the server as you can with a message. And for e-mail it's better to send in plain text, as for web pages I do prefer html.

Message in composition is very different from a webpage. The difference is that TB internally always uses Unicode while you're composing the message - and only keeps a variable describing the charset to which it should try convert the message before sending. But at the point when you want TB to send the message or save it in e.g. Drafts folder, the internal representation must be abandoned and real message needs to be generated. At this point TB has to decide, whether the message fits into the desired charset or not - and take appropriate action. If it doesn't fit into e.g. iso-8859-1, it must be kept in utf-8. But when you return to it via Edit Draft, the message is fetched in utf-8, but your charset variable is initialized according to your preferences - i.e. back to e.g. iso-8859-1. If you change the draft and delete non-fitting characters, the message will be sent in iso-8859-1 even though the saved draft was using utf-8. So there's IMHO no reason to worry - as charset of saved draft does not imply the final charset of the message.

Thanks. Now I understand and am convinced. I should probably lear to read better, because most of the info you gave me is scattered over all the other comments already.

Sorry I could not find previous reports of the bug before I posted my report (436821). The ordinary user will not understand the difference between UTF-8 and Unicode. I had to send trial emails to friends to find out which code retained the Chinese characters (as opposed to converting them to question marks, etc). So, not only is the pop-up window annoying (nagging), it is also confusing, uninformative, and wordy. Surely there is a way to resolve the background save problem without triggering the pop-up window. Making the pop-up window informative when the user finally hits 'Send' would be easier. If they think about it at all, most users will think they've done all they need to do about deciding code when they check or uncheck 'compose messages in HTML format' in the Tools>>Account Settings>>Composition & Addressing.

Given the number of bugreports this behaviour triggers, wouldn't it make sense to backport fix for bug 410333 also to 1.8.1 branch?

If 3.0 is going to be major release, it might make sense to fix this already in the next rebuild of 2.0 -- one less issue to track later. Also, this has been around for nearly four months; a further delay just promulgates the inconvenience.

Sorry, 2.0 only gets security (and crash) fixes at this point.

It's not clear to me what the status of this is...doesn't "RESOLVED WORKSFORME" mean it's not a bug and doesn't need to be fixed? The comments seem to confirm the problem and the intent to fix it. I still see the problem in Thunderbird 3.0.1 (it's been driving me crazy for years!)

Uh, there is no thunderbird 3.0.1. In thunderbird3 (when it gets released) there is no longer the dialog. http://www.mozillamessaging.com/en-US/thunderbird/early_releases/

Heh, sorry about that, I hit the About in Firefox by mistake! Make that Thunderbird version 2.0.0.14 (20080421). Glad to hear about the fix. Is the "RESOLVED WORKSFORME" really correct though? Shouldn't it be "RESOLVED FIXED"? The bugzilla fields definitions page (https://bugzilla.mozilla.org/page.cgi?id=fields.html#status) defines WORKSFORME as "All attempts at reproducing this bug were futile, and reading the code produces no clues as to why the described behavior would occur. If more information appears later, the bug can be reopened."

(In reply to comment #46) > (it's been driving me crazy for years!) Well, you can easily get rid of this dialog by setting Outgoing charset to UTF-8 and checking the option "Use the default character encoding in replies" With such configuration, you won't see the "Send in UTF-8" dialog anymore.

Petr, UTF-8 is unfortunately not problem-free. See bug 410333 comment 21

Incidentally, the "Use the default character encoding in replies" option mentioned in comment #49 is in Options | Display | Fonts..., which is just about the last place I would have looked for it.