default character encoding when composing mail(depreciated windows-1250) is not respected, even though all characters used in mail is defined in windows-1250

RESOLVED WORKSFORME

Status

SeaMonkey
General
RESOLVED WORKSFORME
11 years ago
10 years ago

People

(Reporter: hhgygy, Unassigned)

Tracking

SeaMonkey 1.1 Branch
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070716 SeaMonkey/1.1.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.5) Gecko/20070716 SeaMonkey/1.1.3

In the menu Preferences/Mail & Newsgroups/Character Encoding, I set the default character setting to Central European (Windows-1250) and check in the default character coding option: "Always use this default character coding in replies (When unchecked, only new messages use this default"

Whenever I open a new message for composing, it just "forgets" the default character setting.

Reproducible: Always

Steps to Reproduce:
1. Set the default character setting for COmposing Messages to Central European (Windows-1250)
2. Open a new message for composition
3. Type some diacritical letters

Actual Results:  
4. It says "The message you composed contains characters not found in the selected Character Encoding (...)

Expected Results:  
It should have composed the message in the desired Character Setting and sent it right away.
I can't select this character encoding for composing messages, it's only available for displaying messages here.

But selecting one of the offered encodings (e.g. UTF-8) works for me in SM 1.1.3.
> Central European (Windows-1250)
> 3. Type some diacritical letters

When any diacritical letters in windows 1250?
Problem occurs even when code points defined in windows-1252 only?
(http://www.microsoft.com/globaldev/reference/sbcs/1250.mspx)
(http://www.microsoft.com/globaldev/reference/sbcs/1252.mspx)

DUP of Bug 379480?
(detected as iso-8859-1 => try to convert iso-8859-1 => fail => UTF-8)
Even if DUP, solution can be different. When this bug, option to use default character set always instead of minimum character set can be a solution. (probably already requested)
As Bruno says, windows-1250 is not included in selection list of character encoding for composing(both default in preference and options/Charcter Encoding menu of compose window of Seamonkey 1.1.x).
How did you set windows-1250 as default character encoding for mail composition?
Does problem occur even when Central European(iso-8859-2)?
(Reporter)

Comment 4

11 years ago
It's funny, because after reading your comments, I tried and IT IS THE ONLY Character Encoding that is available for me !

It looks like this: 
Preferences/mail&newsgroups/Character Encoding/

In the Message Display section, the scroll-down menu shows all kinds of encoding, but in the Composing Messages section the scroll-down menu shows nothing but the Central European (Windows-1250) option,

The problem is that this is the most widely used encoding in Hungarian and not the ISO-8859.2
(In reply to comment #4)
> in the Composing Messages section the scroll-down menu shows nothing but the Central European (Windows-1250) option

Is this re-produced with new profile(and dummy POP3 account)?
Do you use non-standard extension(add-on)? 
> The problem is that this is the most widely used encoding in Hungarian and not the ISO-8859.2

However, differences between them are only next two.
 1. Code point of some diacritical letters
 2. Lack of some special marks and Euro-Sign which is covered by use of Unicode
 (See http://en.wikipedia.org/wiki/Windows-1250)
Is iso-8859-2 not usable and meaningless as charset of mail composition for many people in Hungary? 


(Reporter)

Comment 7

11 years ago
> Is this re-produced with new profile(and dummy POP3 account)?
> Do you use non-standard extension(add-on)? 

Yeah it seems that in a new profile I can select other character settings.
I may use them but not sure.

(Reporter)

Comment 8

11 years ago
> Is iso-8859-2 not usable and meaningless as charset of mail composition for
> many people in Hungary? 

It may be as good as Windows-1250, the problem is that
1. I cannot select it
2. Even if I select (the other one) it does not keep the setting 

My intl.charsetmenu.mailedit setting in prefs.js was;
(In both default and current one)
> ISO-8859-1, ISO-8859-15, ISO-8859-6, armscii-8, ISO-8859-13, ISO-8859-14,
> ISO-8859-2, GB2312, Big5, KOI8-R, windows-1251, KOI8-U, ISO-8859-7,
> ISO-8859-8-I, windows-1255, ISO-2022-JP, EUC-KR, ISO-8859-10, ISO-8859-3,
> TIS-620, ISO-8859-9, UTF-8, VISCII
(Default only)
> geostd8, GB18030
(Current one only)
> Shift_JIS, EUC-JP

My profile was created when I used Japanese version of Mozilla. And I never installed extension which changes intl.charsetmenu.mailedit. So I think above lack of geostd8 & GB18030 and additional Shift_JIS & EUC-JP is a result of localization in the past.

What is set as intl.charsetmenu.mailedit in your current profile?
If windows-1250 only, possibly due to over localization in the past.
Reset to default via about:config, and add windows-1250 if required.
What will happen?
(Reporter)

Comment 10

11 years ago
I tried abount:config but nothing changed
(In reply to comment #10)
> I tried abount:config but nothing changed

When I reset intl.charsetmenu.mailedit(Seamonkey 1.1.3/Win XP), Shift_JIS was not included in selection list of Preference/Mail&Newsgroup/Character Encoding/Composing Messages/Default Character Encoding, but when I added Shift_JIS, Shift_Jis appeared in the selection list.
What do you mean by "nothing changed"?
What was not changed after what your operation?
(Reporter)

Comment 12

11 years ago
I'm sorry I didn't understand first what I should do:-(
Now I did reset the intl.charsetmenu.mailedit setting to default
What happened was that I could not select Windows-1250 at all.
I selected however ISO-8859-2 and it seems to be working properly.
Maybe I should forget about Windows-1250 ?
I think removing of windows-1250, windows-1252, Shift_JIS etc. from default of intl.charsetmenu.mailedit means "Let's stop to use them when mail composing".
And even if Bug 379480 occurs on received mail, View/Character Encoding/windows-1250 displays mail properly.
(Reporter)

Comment 14

11 years ago
Update: Sorry folks but ISO-8859-2 does not work for me. It simly does not accept all Hungarian diacritical characters It sends the same error message:
"The message you composed contains characters not found in the
selected Character Encoding (...)
UTF-7 (or UTF-8) works but they are not the most preferred ch.sets for Hungarian
(In reply to comment #14)
> Update: Sorry folks but ISO-8859-2 does not work for me. It simply does not
> accept all Hungarian diacritical characters It sends the same error message:
> "The message you composed contains characters not found in the
> selected Character Encoding (...)

Is all of your "all Hungarian diacritical characters" included in iso-8859-2?
   http://en.wikipedia.org/wiki/ISO-8859-2
If yes, I think it's better to be handled in separate bug. This bug should be kept for problem of comment #0 when windows-1250 as composing charset, although possibly same phenomenon/cause as Bug 379480 or this bug.
 
(Reporter)

Comment 16

11 years ago
I checked the table in the link and yes, all Hungarian characters are included.

I forgot to tell you one more thing (maybe unimportant)
In the top blue frame of the page (sorry I don't know the right word for Windows terminology) when I compose a new message or reply to an existing one, the message subject appears only. In this case, if I try to send the message I get the 
 "The message you composed contains characters not found in the
 selected Character Encoding (...)"
error message.
When I click on the Options/Encoding/Windows-1250 then it will appear next to the subject and then the message can be sent.

An example of the said header, I answer to your message with Reply:
Compose Re: [Bug 390153] default character coding when composing mail
I switch on the Windows-1250 Character Setting and it changes to this:
Compose Re: [Bug 390153] default character coding when composing mail - Central European (Windows-1250)

Also I just noticed that in the Options/Character Encoding menu item 
there is a black dot at the "Central European (Windows-1250)" option as if it was selected (it is my default indeed) 
Still, I have to click on it every time so as to make it effective.
(In reply to comment #16)
> in the Options/Character Encoding menu item there is a black dot at the "Central European (Windows-1250)" option as if it was selected (it is my default indeed)

The "black dot" is indicator of charset currently used. But there is unfortunately no indicator of "chosen as default" or "intentionally chosen by user thru Option/Character Encoding menu".  

> Still, I have to click on it every time so as to make it effective.

Does it mean next?
  If you click Options/Character Encoding/"Central European (Windows-1250)"
  intentionally, "(...) not found in the selected Character Encoding (...)"
  won't appear, and mail is sent with windows-1250.
If so, it indicates that shrinking to minimum charset is executed only when charset thru default, and clicking of Options/Character Encoding is a workaround, although very annoying.   
Adding windows-1250 in summary for ease of search.
hhgygy, please modify it appropriately.
Summary: default character coding when composing mail → default character encoding when composing mail(windows-1250) is not respected, even though all characters used in mail is defined in windows-1250
(Reporter)

Comment 19

11 years ago
> and clicking of Options/Character Encoding is a workaround, although very annoying.   

Yes, I always solve the problem that way but I guessed it must be a bug
How often does "(...) not found in the selected Character Encoding (...)" appear during daily use when you don't intentionally chose windows-1250 via Option menu? If not so frequent, intentional charset choosing is required only when messages is issued, and "Cancel then choose via menu" is a practical workaround when windows-1250.
(Reporter)

Comment 21

11 years ago
(In reply to comment #20)
> How often does "(...) not found in the selected Character Encoding (...)"
> appear during daily use when you don't intentionally chose windows-1250 via
> Option menu? 

I think at least 3 in 4 instances. Sometimes I forget about it and curiously the messages is sent without any error message. (Of course I always mean messages that contain such diacritical letters, when I write only English this is no problem)
"7.1.1. The charset parameter" of rfc 1521 says;
( http://www.ietf.org/rfc/rfc1521.txt )
> In general, mail-sending software must always use the "lowest common
> denominator" character set possible.
Bug 136664 is for this requirement, and is trying to change next modules.
> Bug 136664 - charset in header should use lowest common denominator charset
> /cvsroot/mozilla/mailnews/base/util/nsMsgI18N.cpp
> /cvsroot/mozilla/mailnews/base/util/nsMsgI18N.h
> /cvsroot/mozilla/mailnews/compose/public/nsIMsgCompFields.idl
> /cvsroot/mozilla/mailnews/compose/src/nsMsgCompFields.cpp
> /cvsroot/mozilla/mailnews/compose/src/nsMsgCompFields.h
> /cvsroot/mozilla/mailnews/compose/src/nsMsgCompose.cpp
> /cvsroot/mozilla/mailnews/compose/src/nsMsgSend.cpp
Adding iso-8859-2 to summary, because it seems to be same phenomenon, although different issue may be involved. 
Summary: default character encoding when composing mail(windows-1250) is not respected, even though all characters used in mail is defined in windows-1250 → default character encoding when composing mail(windows-1250/iso-8859-2) is not respected, even though all characters used in mail is defined in windows-1250/iso-8859-2
For iso-8859-2 case.

I tested default composing charaset of iso-8859-2, using Thunderbird trunk 2007/8/01 build(en-US), on Japanese MS Win-XP SP2(locale=Japan, then system codepage=CP932, and Shift_JIS is used internally).

(Test)
I copy&pasted all printable letters higher than 0x80 from following page to a composing mail.
  http://en.wikipedia.org/wiki/ISO-8859-2 (written in UTF-8)
  Pasted letters: 0xA1 to 0xAC, 0xAE to 0xAF, 0xB0-0xFF in iso-8859-2
(Result)
charset=iso-8859-2 was always set both when "Save as Draft" and "Send Later", and no dialog for converting to UTF-8 appeared.

(In reply to comment #14)
> Update: Sorry folks but ISO-8859-2 does not work for me. It simply does not
> accept all Hungarian diacritical characters It sends the same error message:

To hhgygy:   
Is all characters used in the mail defined in iso-8859-2?
(Please note that Euro-Sign is not defined in iso-8859-2)
What is you locale or code page?
(CHCP in command prompt will display default codepage)
(Reporter)

Comment 25

11 years ago
> Is all characters used in the mail defined in iso-8859-2?
Yes they are
> (Please note that Euro-Sign is not defined in iso-8859-2)
> What is you locale or code page?
> (CHCP in command prompt will display default codepage)
852

(In reply to comment #25)
> > Is all characters used in the mail defined in iso-8859-2?
> Yes they are

Can you test same case as mine in comment #24(copy&paste) with default composing charset of iso-8859-2 using Tb 2.0.0.x?
(Reporter)

Comment 28

11 years ago
I tested it simply by typing the notorious Hungarian diacritical letters 
éáűőúüóöí ÉÁŰŐÚÜÖÓÍ
It worked for me both in ISO-8859-2 and Windows-1250
Also, after selecting the drafts for Edit as New and sending worked smoothly, and received all characters properly
(In reply to comment #28)
> I tested it simply by typing the notorious Hungarian diacritical letters 
> It worked for me both in ISO-8859-2 and Windows-1250

What is the difference from your comment #0(windows 1250 case) and comment #14(iso-8859-2 case)?
(Reporter)

Comment 30

11 years ago
The main point was (as far as I remembered) that with ISO-8859-2 composing mail might work without pre-selecting the character set.
In this test you gave to me I always pre-selected the appropriate setting, but the initial problem is that the "default setting for new messages" does not work (i.e. without a second pre-selection) for Windows-1250.
Anyway, I checked out my correspondence and it seems that ISO-8859-2 displays identically all my incoming and outgoing messages so maybe I should switch to this as my default.
(In reply to comment #30)
> Anyway, I checked out my correspondence and it seems that ISO-8859-2 displays
> identically all my incoming and outgoing messages so maybe I should switch to
> this as my default.

Question to clarify problem in your environment.
(Q1) It sounds that there is no problem when default composing charset is iso-8859-2. If so, what does your comment #14 mean? 
(Note: When windows-1250, Bug 379480 exists, and it can affect your problem.)
(Further, windows-1250 is already depreciated as mail composing charset,    )
(then lack of care on windows-1250 in mail composing is not so funny,       )
(and it is acceptable and I believe we should accept WONTFIX even if this is)
(real "bug" when windows-1250-case.                                         )
(Reporter)

Comment 32

11 years ago
I think comment #14 was made when I did not reset the intl.charsetmenu.mailedit setting to default. I just simply checked it as the default character setting but the same error seemed to come up.

I should try it a bit more whether in the current setting, it works smoothly but I have to work now so it may take some more time. 
(Reporter)

Comment 33

11 years ago
> (Q1) It sounds that there is no problem when default composing charset is
iso-8859-2.

Update: since I switched to ISO-8859-2 I haven't ever encountered the error message
(In reply to comment #33)
> Update: since I switched to ISO-8859-2 I haven't ever encountered the error message
It's very good news! Removing iso-8859-2 from bug summary.
Summary: default character encoding when composing mail(windows-1250/iso-8859-2) is not respected, even though all characters used in mail is defined in windows-1250/iso-8859-2 → default character encoding when composing mail(obsoleted windows-1250) is not respected, even though all characters used in mail is defined in windows-1250
Summary: default character encoding when composing mail(obsoleted windows-1250) is not respected, even though all characters used in mail is defined in windows-1250 → default character encoding when composing mail(depreciated windows-1250) is not respected, even though all characters used in mail is defined in windows-1250
Version: unspecified → SeaMonkey 1.1 Branch

Comment 35

10 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008052102 SeaMonkey/2.0a1pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9

I can't reproduce this bug.

I close this for now as wfm.
Reporter, if you still run into this problem while using an recent Build,
please reopen and submit actual information.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.