92625 - When sending mail, charset should be checked *before* we start sending.

Status: RESOLVED WORKSFORME

(MailNews Core :: Composition, defect)

Description

[Aleksey Nogin]

If the composed message has a charset that disagrees with its contents, the
warning message would pop-up *after* the "Send progress" window. And if we chose
"Cancel" on charset warning message (e.g. Cancel the send and go re-edit the
message), the send progress window does not go away and Mozilla still thinks
that the message is in process of being sent!

Reproducible: always
To reproduce:
1) "New Msg"
2) In Compose Window: View -> Character Coding -> Western
3) Type some cyrillic stuff in the composed message.
4) Press send.

Actual:
Two windows pop up. The first is the "Confirm" window saying "The message you
composed contains characters not found in the selected Character Coding. ..."
The second one is the "Sending Messages" progress status window.
Additionally, the prograss bar in the Compose window starts "running around"
like when the message is being sent.

Expected: Only "Confirm" window should pop up. Only if and when I choose "OK" in
the "Confirm" window, Mozilla should go into the "Sending Messages" state.

P.S. Note that both the spellchecker window and the epmty subject warning window
come up (correctly) before the "Sending Messages" state, so only the charset
window is a problem.

I am using Mozilla 0.9.2 (from mozilla.org RH7 RPMs) on RedHat Linux 7.1

Comment 1

[David Woolley]

It would be helpful if the problem characters were also highlighted. Specifally,
there is a large overlap between big5 and gb2312, but some gb2312 characters
will fault in big5 (I'm really going Unicode from Windows Simplified Chinese IME
to Big 5, rather than GB2312 to Big 5.)  At the moment, one has to send the
message and look for the question marks to find out what was rejected.

Comment 2

[Dimitrios]

Actually, this bug is a dupe of bug 91663 (which reports the issue, while this
one suggests the solution). A fix for this one would automatically fix bug 91663
(and, bug 89655 easier to fix, imho). 

Comment 3

[Aleksey Nogin]

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

Comment 4

[Dimitrios]

Suggesting OS=All (I am seeing this on Win32, as I reported in bug 91663).
Somehow I think the importance of a bug increases if it happens on all platforms
(OK, maybe OS categorisation is trivial, who knows...)

Comment 5

[Jean-Francois Ducarroz]

This has been fixed a while ago.