Dmitri Galter Reporter
	Description • 23 years ago

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2001122106

When you type/paste a text into mail editor, it is impossible to change font
enconding for this text (or the whole message for that matter) later on (as it
was easily possible in Netscape 4.7x series, or in the mail viewer window). The
ability to change encoding is essential when working with certain foreign
language applications.

Reproducible: Always
Steps to Reproduce:
1. Prepare test message in encoding other than Western (say, Cyrillic)
2. Go to View->Character Encoding and choose another encoding (say, Western)


Actual Results:  No effect noticed (the same action in mail viewer window will
actually change the encoding).

Expected Results:  Change the character encoding of the message (even if
"gibberish" characters appear)

	Sheela Ravindran
	Comment 1 • 22 years ago

change qa contact based on reporters comments. 

	Boris 'pi' Piwinger
	Comment 2 • 22 years ago

Is this still a problem in 1.1 or later?

pi

	Dmitri Galter Reporter
	Comment 3 • 22 years ago

Yes, it's still a problem in 1.1.

	marina
	Comment 4 • 22 years ago

i can confirm that in 4.79 after attempting to change encoding of the message
one would get a warning message about the consequences of that change (will rend
chars unreadable), in case you click "OK" the message will change encoding , in
some cases would be gibberish, like changing from cyrillic to western. In the
current release there is no warning dlg coming up and no change in the charset
occurs. 

	Jean-Francois Ducarroz Assignee
	Comment 5 • 22 years ago

accepting

	Marcin Gryszkalis
	Comment 6 • 22 years ago

Confirmed. 
For me the problem is most annoying when replying to mail.
Eg. when replying to news-post encoded in non-standard
Windows CP-1250 CP I cannot change it (to proper ISO-8859-2)
and I have to send the netiquette-invalid post.

Note that target milestone is invalid.
I guess it cannot be set as 1.3 blocker but it IS 
important (if we keep Moz-evangelism in mind).

My build is 2003021708 trunk, Windows 2000.

	Mike Cowperthwaite
	Comment 7 • 21 years ago

Is this bug still a problem?  I'm not able to reproduce the symptom with 1.6 or 
1.7b.

	Dmitri Galter Reporter
	Comment 8 • 21 years ago

The bug is still a problem as of 1.7b.

	Mike Cowperthwaite
	Comment 9 • 21 years ago

Rereading the bug, I think that what you are asking for would worsen the program 
behavior.  During composition, the display is always Unicode -- whether you've 
selected ISO-8859-1 or Big5 for your character set, you can still display 
Cyrillic or Arabic or Japanese characters in the editing window.

The encoding that's been selected is used when the message is prepared for 
sending.  At that time, if any of the characters you have entered are not part 
of the selected encoding, Mozilla will attempt to find an alternate encoding -- 
usually by asking you if you want to automatically convert to Unicode (UTF-8) or 
allowing you to change the encoding.  Alternately, if a fallback preference[*] 
has been set, Mozilla will try the characters sets listed in that preference, 
and only ask if none of the fallback sets contain all the characters used in the 
mail composition. (However, see bug 197344 and bug 169761.)

I recommend this bug be resolved as INVALID or WONTFIX.

[*] The fallback preferences are named like:
   intl.fallbackCharsetList.ISO-8859-1
   intl.fallbackCharsetList.Big5
and are set to strings containing a comma-separated list of alternate character 
sets, such as:    ISO-8859-2,UTF-8
If the composed message's selected character encoding is ISO-8859-1, then the 
preference that will be used is:  intl.fallbackCharsetList.ISO-8859-1

	Dmitri Galter Reporter
	Comment 10 • 21 years ago

Whatever. Unfortunately, since I logged the bug 2+ years ago,
I permanently switched to from Mozilla to Opera (including
email handling), and also stopped using the software application
for which this ability to switch encodings was needed in
the first place. So I just don't care anymore.

However, other people still do care, and the bug should
not be closed just because I stopped using Mozilla. Please
see Marcin Gryszkalis' reply, he sees an issue here as well.

	Marcin Gryszkalis
	Comment 11 • 21 years ago

I tested it again.

It seems to work as Mike described, but I'm not sure if it's expected behavior.
The problem is that "convert on send" is not consistent with menu option
(View/Change Encoding) - view is view, it should change displayed meesage
immediately. 

So, maybe it could be solved via UI changes? 

Another issue is the preference Mail/Composition/Characeter Encoding
and checkbox "Always use this deafult encoding...".
It would be very helpful but it seems to be useless.
It changes the encoding but doesn't do mapping so the result is
broken. This could be replaced with "Always change encoding
to the deafult on send".

Expected flow of events is:
1. receive email in CP-1250
2. [reply]
3. Reply uses UTF-8 so the oryginal content is rendered properly, I can add some
new text, everything is ok.
4. I choose Options/Sending-Encoding and then ISO-8859-2
5. [send]
6. Mozilla checks if the message can be sent in choosen (ISO-8859-2) encoding,
if not it prompts with usual question ("not all characters...")
7. message is sent

Alternate expected flow of events:
1-3. as above
4. [send]
5. "Always change encoding to the deafult on send" is set, so Mozilla tries to
send the message in default encoding (eg. ISO-859-2)

Alternate (2) flow:
1-4. as above
5. "Always change encoding to the deafult on send" is NOT set, Mozilla tries to
send the message in oryginal encoding (CP-1250)

	Mike Cowperthwaite
	Comment 12 • 21 years ago

(In reply to comment #11)
> The problem is that "convert on send" is not consistent with menu option
> (View/Change Encoding) - view is view, it should change displayed meesage
> immediately. 
> 
> So, maybe it could be solved via UI changes? 

I agree that the encoding option is probably in the wrong place; in fact, 
there's an old bug about that already: bug 92499.


> Another issue is the preference Mail/Composition/Characeter Encoding
> and checkbox "Always use this deafult encoding...".
> It would be very helpful but it seems to be useless.
> It changes the encoding but doesn't do mapping so the result is
> broken. 

I'm not sure what you mean by this.  What should be mapped?
I just tried that checkbox, replying to an ISO-2022-JP mail, and the encoding 
for the reply was forced to ISO-8859-1, my default.  When I sent the message, it 
was converted to UTF-8 because I've got the fallback set for that.

	Marcin Gryszkalis
	Comment 13 • 21 years ago

(In reply to comment #12)
> I agree that the encoding option is probably in the wrong place; in fact, 
> there's an old bug about that already: bug 92499.
There's also similar complaints in bug 58143 (linked to 92499)

> > Another issue is the preference Mail/Composition/Characeter Encoding
> > and checkbox "Always use this deafult encoding...".
> > It would be very helpful but it seems to be useless.
> > It changes the encoding but doesn't do mapping so the result is
> > broken. 
> I'm not sure what you mean by this.  What should be mapped?
> I just tried that checkbox, replying to an ISO-2022-JP mail, and the encoding 
> for the reply was forced to ISO-8859-1, my default.  
I meant mapping=conversion
Are japanese charaters displayed correct after forced change to iso-8859-1?
Do they look ok after you receive this utf-8 encoded reply?

	Mike Cowperthwaite
	Comment 14 • 21 years ago

> Are japanese charaters displayed correct after forced change to iso-8859-1?
> Do they look ok after you receive this utf-8 encoded reply?

Yes, they came across fine with the automatic fallback conversion.  However, the 
issue described in bug 169761 is still a problem.

I think bug 58143 is only a display issue, and in my mind it has been addressed 
since any charset other than the default is displayed in the titlebar.

	Marcin Gryszkalis
	Comment 15 • 21 years ago

(In reply to comment #14)
> > Are japanese charaters displayed correct after forced change to iso-8859-1?
> > Do they look ok after you receive this utf-8 encoded reply?
> Yes, they came across fine with the automatic fallback conversion.  However, the 
> issue described in bug 169761 is still a problem.

Ok, I found the reason why it behaved wrong in my case - during test I turned on
"force display encoding" (prefs/Mail/Message display/Apply default to
all messages). It seems that it affects compose too.
So - I agree it's UI-only issue now.

> I think bug 58143 is only a display issue, and in my mind it has been addressed 
> since any charset other than the default is displayed in the titlebar.

Yes, it is, I guess it could be closed.

	Mike Cowperthwaite
	Comment 16 • 21 years ago

OK, I'm resolving this bug as WorksForMe -- because I don't know exactly how 
Mozilla was behaving in this regard prior to 1.5, maybe there was something 
being done incorrectly when this bug was filed.  (I think the fallback pref is 
relatively recent.)  The people with votes on this might want to move their 
votes to another bug, such as the related bug 197344.

	Marcin Gryszkalis
	Comment 17 • 21 years ago

> The people with votes on this might want to move their 
> votes to another bug, such as the related bug 197344.

or the UI change request - bug 92499