311821 - Unnecessary prompt "Wait/Quit" when closing compose after "Convert to Unicode" cancelled

Status: RESOLVED DUPLICATE of bug 328938

(MailNews Core :: Composition, defect)

Description

[Seungbeom Kim]

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 ]

Comment 1

[Mike Cowperthwaite]

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.

Comment 2

[WADA:World Anti-bad-Duping Agency]

Duping to Bug 328938 although this bug is older discovery of the problem, because discussion for solution is already in progress in Bug 328938.       

Comment 3

[Andrew Birkett]

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.

Comment 4

[Andrew Birkett]

Attachment: Suggested patch to stop wait/quit dialog appearing after cancelling utf8 dialog