Closed
Bug 122420
Opened 23 years ago
Closed 21 years ago
unable to change font encoding in mail compose (editor) window
Categories
(MailNews Core :: Internationalization, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
mozilla1.2beta
People
(Reporter: dgalter, Assigned: bugzilla)
Details
(Keywords: intl)
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)
Reporter | ||
Updated•23 years ago
|
URL: http://n/a
Reporter | ||
Updated•23 years ago
|
Component: Composition → Internationalization
Comment 1•23 years ago
|
||
change qa contact based on reporters comments.
QA Contact: sheelar → marina
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.
Assignee | ||
Comment 5•22 years ago
|
||
accepting
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2beta
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.
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.
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
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.
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)
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.
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?
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.
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.
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.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
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
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•