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)
Tracking
(Not tracked)
NEW
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.
Comment 2•23 years ago
|
||
Is this reproducible with NS6.0?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.8
related: bug 111711
Comment 6•23 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.
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → ---
Updated•23 years ago
|
Target Milestone: --- → mozilla1.2
Updated•22 years ago
|
Target Milestone: mozilla1.2alpha → ---
Comment 7•22 years ago
|
||
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 8•21 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
bug.
Attachment #59038 -
Attachment is obsolete: true
Updated•20 years ago
|
Product: MailNews → Core
Assignee | ||
Updated•16 years ago
|
Product: Core → MailNews Core
Updated•15 years ago
|
QA Contact: ji → i18n
Comment 9•14 years ago
|
||
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
Comment 10•14 years ago
|
||
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
Updated•14 years ago
|
Flags: wanted-seamonkey2.1?
You need to log in
before you can comment on or make changes to this bug.
Description
•