Open Bug 110750 Opened 23 years ago Updated 14 years ago

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

Categories

(SeaMonkey :: MailNews: Composition, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: kalin, Unassigned)

Details

(Keywords: intl)

Attachments

(1 obsolete file)

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
somehow.


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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl
Is this reproducible with NS6.0?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
Yes, same problem on 6.0.
related: bug 111711
Attached image Snapshot 1 (obsolete) —
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.
Target Milestone: mozilla0.9.8 → ---
Target Milestone: --- → mozilla1.2
Target Milestone: mozilla1.2alpha → ---
This might have been related to the back-end RDF source changes checked in on
November 1, 2001 (bug 64146,
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/xpfe/components/intl/nsCharsetMenu.cpp).
  I suspect that it's been addressed by some of the subsequent checkins.
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
bug.
Attachment #59038 - Attachment is obsolete: true
Product: MailNews → Core
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
Status: ASSIGNED → UNCONFIRMED
Component: Internationalization → General
Ever confirmed: false
Product: MailNews Core → SeaMonkey
QA Contact: i18n → general
Version: Trunk → unspecified
I can confirm it with Comment 8 and:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10pre) 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.
Status: UNCONFIRMED → NEW
Component: General → MailNews: Composition
Ever confirmed: true
Flags: wanted-seamonkey2.1?
OS: Windows 98 → Windows XP
QA Contact: general → mailnews-composition
Version: unspecified → Trunk
Flags: wanted-seamonkey2.1?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: