User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7 Build Identifier: Mozilla Thunderbird version 1.0.7 (20050923) Once you try to save a message that contains characters not in the character encoding and cancel the saving, a wrong dialog box appears when you try to cancel the composition and close the window. Reproducible: Always Steps to Reproduce: 1. Open a new compose window. 2. Type in some characters that are not in the character encoding. (For example, some Korean characters under ISO-8859-1 encoding.) 3. Try Ctrl-S to save the message as a draft. 4. Hit Esc or Cancel at the confirm dialog box. 5. Try to close the compose window. Actual Results: The following dialog box appears: "Sending Message" Mail is currently in the progress of sending a message. Would you like to wait until the message has been sent before quitting or quit now? [ Wait ] [ Quit ] Expected Results: Since it's not actually in the progress of sending a message, it should instead display this dialog box: "Save Message" Message has not been sent. Do you want to save the message in the Drafts folder? [ Save ] [ Don't Save ] [ Cancel ]
This is true, and it's kind of annoying, and it's been a problem for a long time. I've looked around for a dupe with no luck. At least, there's no dataloss involved -- if you decide to send the message, or to save it again, rather than trying to close the window, it'll do that; and if you click Wait, it'll go back to the state where you can send, save or try again to close (with the same dumb prompt). As bug 328833 points out, if you happen to enter characters that don't belong while composing with AutoSave turned on, you start getting the "Convert to Unicode / Send Anyway" prompt at the first attempt to save. A workaround to avoid this problem: for whatever your default charset is, create a 'fallback' preference. Mozilla provides one by default: intl.fallbackCharsetList.ISO-8859-1 but you can create one for ISO-8859-15 or ISO-2022-JP or whatever you normally use. Set the value of the pref to "UTF-8". Then whenever a message contains characters outside the normal charset, it will automatically convert to UTF-8 on sending or saving.
Assignee: mscott → nobody
Status: UNCONFIRMED → NEW
Component: Message Compose Window → MailNews: Composition
Ever confirmed: true
OS: Windows XP → All
Product: Thunderbird → Core
QA Contact: composition
Hardware: PC → All
Summary: Incorrectly shows "Sending Message: Wait/Quit" dialog box → Unnecessary prompt "Wait/Quit" when closing compose after "Convert to Unicode" cancelled
Version: unspecified → Trunk
Duping to Bug 328938 although this bug is older discovery of the problem, because discussion for solution is already in progress in Bug 328938.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 328938
I've just stumbled across this bug myself today. I don't agree that it's a dupe of Bug 328938 however since that refers to the inconvenience of having the 'convert to utf-8' dialog popping up during autosave. I can reproduce this wait/quit bug without involving autosave, as follows: 1. Compose new email (my default encoding is iso-8859-1) 2. Enter a non iso-8859-1 character into the email body 3. Hit send 4. At the "convert to utf-8" dialog, hit cancel. 5. Close the compose window, and you get an erroneous "wait/quit" dialog. The root problem here is that when you say "cancel" to the "convert to utf8', the gSendOrSaveOperationInProgress flag is not being set back to false here: http://lxr.mozilla.org/seamonkey/source/mail/components/compose/content/MsgComposeCommands.js#1891 This code path is executed whether you autosave, manually save, or directly send the email .. in all three cases, cancelling the 'convert to utf8?' dialog leaves this global variable in the wrong state. I'll attach a patch to this bug which fixes this.
Created attachment 295032 [details] [diff] [review] Suggested patch to stop wait/quit dialog appearing after cancelling utf8 dialog
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.