in mail, menu View|Character Coding|Customize... inconsistence after customization



MailNews: Composition
17 years ago
8 years ago


(Reporter: Kalin Kozhuharov, Unassigned)



Windows XP

Firefox Tracking Flags

(Not tracked)



(1 obsolete attachment)



17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.5) Gecko/20011011
BuildID:    2001101117

When creating new messages (only??) if one sets the Character Coding to coding X
and then uses the Customize menu, the Character Coding is lost... (May be goes
to default?)

Reproducible: Always
Steps to Reproduce:
1.Create new mail message.
2.Set the coding to, say Windows-1251.
3.Use the View|Character Coding|Customize... menu to reorder the selected menus

Actual Results:  The Character Coding is lost! See the titlebar for example.

Expected Results:  The Character Coding should be preserved!

I haven't look at the code, but is the coding stored as a reference to the
number in the Customize... menu?

Or is the coding reset each time after Customize... is used? Why?

After steps 1 to 3 there is no mark (blob) in front of any item in
View|Character Coding.

My Win98 is Japanese SP2 for the record.

Comment 1

17 years ago
Confirmed the bug with 11/16 trunk and 6.2 build. 
After revoking customize window, the charset shown on the title bar is gone
although the charset chosen for compose window is different with the global
default one.
Ever confirmed: true
Keywords: intl

Comment 2

17 years ago
Is this reproducible with NS6.0?
Target Milestone: --- → mozilla0.9.8

Comment 3

17 years ago
Yes, same problem on 6.0.

Comment 4

17 years ago
related: bug 111711

Comment 5

17 years ago
Created attachment 59038 [details]
Snapshot 1

Comment 6

17 years ago
I cannot reproduce this on my debug build (win32, pulled today).
I added windows-1252 to the mail compose menu, the invoked the preference, the 
default compose item was set to ISO-8859-1.


17 years ago
Target Milestone: mozilla0.9.8 → ---


17 years ago
Target Milestone: --- → mozilla1.2


16 years ago
Target Milestone: mozilla1.2alpha → ---
This might have been related to the back-end RDF source changes checked in on
November 1, 2001 (bug 64146,
  I suspect that it's been addressed by some of the subsequent checkins.

Comment 8

15 years ago
Comment on attachment 59038 [details]
Snapshot 1

I don't think this screenshot has something to do with this bug.

The original bug is still present in recent builds:

1. Compose a message.
2. Select a character coding in View|Character Coding.
3. Notice the selected character coding is now marked as selected in the menu.
4. Select View|Character Coding|Customize...
5. Reorder something in the Active Character Coding listbox.
6. Press Ok.
7. Notice that now nothing is selected in View|Character Coding. This is the
Attachment #59038 - Attachment is obsolete: true
Product: MailNews → Core


10 years ago
Product: Core → MailNews Core
QA Contact: ji → i18n
Not reproduce on Thunderbird 3.1 and menu structure of current is too difference.

This bug is reported for original Mozilla Suite Application, so I change product to SeaMonkey.
Assignee: nhottanscp → nobody
Component: Internationalization → General
Ever confirmed: false
Product: MailNews Core → SeaMonkey
QA Contact: i18n → general
Version: Trunk → unspecified

Comment 10

8 years ago
I can confirm it with Comment 8 and:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20100406 SeaMonkey/2.0.5pre
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a4pre) Gecko/20100405 SeaMonkey/2.1a1pre

Setting encoding is on Compose window in Options - Character Encoding not in View - Character Encoding.

When I sended message, receive message is view in default encoding.
Component: General → MailNews: Composition
Ever confirmed: true
Flags: wanted-seamonkey2.1?
OS: Windows 98 → Windows XP
QA Contact: general → mailnews-composition
Version: unspecified → Trunk


8 years ago
Flags: wanted-seamonkey2.1?
You need to log in before you can comment on or make changes to this bug.