57083 - Message lost after canceling the char code warning.

Status: VERIFIED FIXED

(MailNews Core :: Networking, defect, P3)

Description

[hirata masakazu]

When a character code warning appears on Save(bug 577080), you have a choice of
"Confirm to Send"(which is wrong in this context) and "Cancel"(supposed to go
back to compose window).
But the result is "Confirm to Send" brings you back to compose window while
"Cancel" just close the window and the message gets lost.
There should be a way to guarantee that the composed text not be lost at all in
the context of any other bug.

Comment 1

[hirata masakazu]

Ooops. That Bug no. is 57080.  However, 57080 has changed a bit.  So, to get the
char code warning: You type Japanese text in the Subject while the char coding
is actually set to Western(ISO8859-1).  Then Save as Draft.

Comment 2

[hirata masakazu]

In today's build, the bahavior I saw different behavior.
The only case I got message lost was:
1)Open message compose by New Message. (ISO-8859-1 is the default.)
2)Compose in Japanese.
3)Click close switch in the window title bar.
4)Mozilla asks if you want to save or not, and you choose to save.
5)Character code warning for Send appears, and you choose to cancel as suggested
by the text in the warning so you can go back and select the coding.
6)Compose window disappears and the message is lost.
Obviously, "Cancel" in 5) is behaving as the same as "Don't save" instead of
"Cancel" in the dialog that appears in 4).

Comment 3

[Asa Dotzler [:asa]]

setting bug status to New

Comment 4

[Christopher Blizzard (:blizzard)]

Nominating for 0.8.

Comment 5

[Jean-Francois Ducarroz]

cc'ing nhotta who wrote the char warning dialog stuff.

Comment 6

[nhottanscp]

cc to IQA, is this still reproducible?

Comment 7

[scottputterman]

nominating means putting in the keywords, not in the target milestone. I'm
nominating nsbeta1 which will put this on the radar.  reassigning to nhotta
since it sounds like he's the one who wrote this.

Comment 8

[marina]

it doesn't happen with 2001-02-01-04 build, after clicking 'Cancel' you're back
to Compose window and you can change char coding (though the window looses focus)

Comment 9

[nhottanscp]

Marina, did you test Macintosh build?

Comment 10

[marina]

yes, Mac 9.0 and it's fixed

Comment 11

[nhottanscp]

Mark as WORKSFORME, please reopen if reproducible.

Comment 12

[hirata masakazu]

I tested in 2001020108 and it is still happening.
You have to follow the steps precisely in 10-24 posting. It happens when you try
to save it first and get the char code warning, then try to go back->you can not.
Reopening.

Comment 13

[marina]

The  case of Canceling the Send operation with different endings is fixed.
Cancel the "Save to Drafts" is still loosing the compose window, so confirming
the reopening.

Comment 14

[nhottanscp]

Functions in the JS code do not return error codes in many cases (e.g. 
SaveAsDraft, GenericSendMessage).
Because SaveAsDraft does not return error code, the caller cannot know if the 
save as succeeded or not. So it closes the window even if the user hit the 
cancel button.
I will try to change the functions to return error but the change would be 
non-trivial.
Jean-Francois, is this (ignoring the error) is done intentionally?

Comment 15

[Jean-Francois Ducarroz]

If I remember right, those process are asynchronous, therefore returning an
error code want solve the problem. The right place to look is in the listener
function OnStopRequest, probably nsMsgComposeSendlistener::OnStopRequest

Comment 16

[nhottanscp]

You are right, so the JS code cannot know about the error and always close the
window.
So I am seing nsMsgComposeSendListener::OnStopSending is called after the window
is gone.
We could check the charset conversion error before we actually send (like the
spell checking). But that's an overhead since we need to convert the sending
text twice just to make sure for no convesion error.
Or we may change to pop up the multilingual alert only for send now, not for
save as draft, send later, etc.
Jean-Francois, what do you think?

Comment 17

[Jean-Francois Ducarroz]

We are not closing the window but just hidding it when we send/save a message.
When we receive the OnStopRequest call, we look if we get have an error. If yes
we show back the window else we close the window. Therefore, you need to check
in OnStopRequest if we correctly detect the error.

Comment 18

[nhottanscp]

I cannot find OnStopRequest for nsMsgComposeSendListener, can I do the error
check in OnStopSending.

Comment 19

[Jean-Francois Ducarroz]

sorry, I mean OnStopSending.

Comment 20

[nhottanscp]

Or nsMsgComposeSendListener::OnStopCopy, since this bug happens when saving as
draft?

Comment 21

[Jean-Francois Ducarroz]

right.

Comment 22

[nhottanscp]

I found it does not hit OnStopCopy() because the error happens in 
nsMsgCompose::SendMsg before the thread for save message is created.
And the window is always closed by the JS code below regardless of the error. 
This is a special situation that the user explicitly closed the window then we 
ask if the document should be saved or not. So the only case the window does not 
close is when the user hit cancel at the first alert ("want to save?") and 
ComposeCanClose() returns false. All other cases, the window is closed.

513 function DoCommandClose()
514 {
515   if (ComposeCanClose())
516     CloseWindow()
517 }
518 

Comment 23

[nhottanscp]

So, I cannot check the error in OnStopCopy.
I will try if I can check the charset conversion error in JS, or enable the
alert only for send now.

Comment 24

[nhottanscp]

I tried the conversion check in JS. It is possible to catch a conversion error 
in JS. So we can ask the user if the user wants to go back to the editor before 
appling the real conversion in cpp part.
But if the user wants to save it anyway, then we proceed and do the real 
conversion in cpp code and the user would be asked again about the same 
conversion error. There is no way to detect every unconvertible character and 
discard them before calling the cpp code, so we cannot avoid alerting the user 
twice.
So my current plan is to enable the alert for send now only.

Comment 25

[hirata masakazu]

Is it difficult to have a general fix for "message lost after send error" like
bug 55236? 

Comment 26

[nhottanscp]

I may be able to take advantage if there is a fix for bug 55236. The JavaScript
code needs to catch the send error (including asynchronous one) to avoid closing
the compose window.

Comment 27

[nhottanscp]

There is another instance of the problem.
When I set a draft folder as IMAP folder then do the same step as this bug with 
all ASCII text. After canceling the password dialog, the windows is closed and 
the data is lost.

Comment 28

[nhottanscp]

Attachment: Patch, do multilingual alert only for send now.

Comment 29

[Jean-Francois Ducarroz]

R=ducarroz

Comment 30

[David :Bienvenu]

sr=bienvenu for the workaround.

Comment 31

[nhottanscp]

checked in

Comment 32

[esther]

Marina, can you test this one too since you verified 57080.  What's left of 
this bug requires bringing up the character code warning during a Save as Draft 
operation.  Cancelling it to see if the Compose window is still up front.  If 
you can't verify this, can you instruct me again on how to type Japanese text in 
the Subject while character coding is set to Western (ISO-8859-1).  

Comment 33

[marina]

Naoki, aren't we supposed to have a warning when saving to Drafts a message with
different encodings??? i don't see it coming up when i am saving a japanese
message with iso-8859-1, only in the Send operation

Comment 34

[marina]

assigning QA to myself

Comment 35

[nhottanscp]

It was changed to alert for send now only.

Comment 36

[marina]

then how can we Save to Drafts correctly if no warning comes up? when different
encodings are not detected the message copied to Drafts becomes unreadable.

Comment 37

[nhottanscp]

It is a workaround to avoid losing everything which may happen in the situation
as describled in this bug.

Comment 38

[marina]

the scenario described in this bug report (loosing a message after canceling the
warning dlg)is not happening any more though the workaround doesn't prevent the
user from Saving in the wrong charset to Drafts: Verifying 

Comment 39

[Aleksey Nogin]

Bug 89655 (No charset confirmation dialog when "Send Later" is used) and bug
104135 (Save as -> Draft should produce a charset mismatch warning) ask for the
restoration of the charset dialog for "Send Later" and "Save as Draft".