If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Customize Character Encoding: Decide the status of ISO-8859-1 entry - it should either be truly removable -or- unremovable and grayed out

RESOLVED INVALID

Status

MailNews Core
Internationalization
--
major
RESOLVED INVALID
15 years ago
3 years ago

People

(Reporter: Wesha, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a+) Gecko/20020708
BuildID:    2002070804

News component doesn't properly recognize the encoding for some Russian
newsgroups. To prevent it from even trying Western ISO8859-1, I try to remove it
from the list, but it slips back onto it again.

Reproducible: Always
Steps to Reproduce:
1. Open News component
2. Go to View->Character Encoding->Customize
3. On the left pane, select Cyrillic (KOI-8R); click ADD
4. On the right pane, select Western (ISO-8859-1); click Remove
5. Click OK.
6. Repeat step 2

Actual Results:  ISO-8859 is still there, ignoring the fact that it has just
been removed.

Expected Results:  No ISO-8859 should be on the list, only KOI-8R added during
step 3.
Confirmed linux trunk cvs 2002-07-11. After being removed from the active list
in the customize dialog, ISO-8859-1 re-appears there upon next view of the
customize dialog, whether others were added to active list or not.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All

Updated

15 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → Future
I believe there was some issue related to this when we designed the dialog.
Latin-1 is hard coded in various parts of the app as a fall-back value and
removing it from the charset menu resulted in some issues. I can't remember
which though - I'll rummage.

An easy fix would be to stop calling AddRemoveLatin1:

http://lxr.mozilla.org/seamonkey/source/xpfe/components/prefwindow/resources/content/pref-charset.js#29
>To prevent it from even trying Western ISO8859-1

Oh, I seem to remember now. This is *exactly* why we always wanted to have
Latin-1 in the menu. Before we had UI to manipulate intl.charset.default,
ISO-8859-1 was effectively hard coded as an application default. Since the UI
should be consistent with the backend's behavior, Latin-1 cannot be removed from
the menu.

The default fall-back charset has been exposed via the Languages preference
panel, meaning that the UI is not 100% now. However, Latin-1 remains our last
line of defence. See here:

http://lxr.mozilla.org/seamonkey/source/content/base/src/nsDocumentViewer.cpp#2306

I recommend invalidating this bug. The only way to keep it open would be to
request making the intl.charset.default value non-removable as well. If we
decide to do that, intl.charset.default should have precedence over ISO-8859-1
to correctly reflect Gecko's behavior

changing summary: ISO-8859-1 and intl.charset.default shouldn't respond to the
remove button.

These two values should perhaps appear grayed out to help set user expectations.
Summary: Customize Character Coding: unable to remove ISO-8859-1 from the list → Customize Character Coding: ISO-8859-1 and intl.charset.default shouldn't respond to the remove button
(Reporter)

Comment 5

15 years ago
Hey guys, I object!!! You're missing the whole point here.

I tried to remove ISO-8859-1 in the first place because I had message headers in
the News that are actually in KOI8-R displayed in ISO-8859-1. Of course I
immediately put KOI8-R in and tried to remove ISO-8859-1 to force it to use KOI.

We shouldn't fall back to ISO, we should TRY to fall back to the available
charsets first, and if there's no available, only then to ISO.
wesha,

I'm sorry to say that, but that's not how the menu works. The customization
dialog was intended as a way to keep the menu short -- i.e. customized. And the
menu was intended for manual charset changes, not for setting application
defaults :-)

Obviously, you have logged this bug because the product didn't behave according
to your expectations. However, we cannot be very flexible with back-end behavior
changes and it's up to the front-end to set proper expectations and expose
meaningful ways of interacting with the back-end.

To achieve the results you intended, you'll need to go to the preference panel
"Edit->Preferences->Mail&Newsgroups" and change the encoding default there.

I agree that this is not the most intuitive way of doing it and filing a bug
about it would be certainly warranted. IMHO what we failed to convey in the
charset customization dialog is the fact that the defaults are not removable.
And they are not removable, because they are set somewhere else :-)  It would be
wrong to indicate something else.

Comment 7

15 years ago
right, the menu customization is unrelated to message display fallback mechanism.
Created attachment 97878 [details] [diff] [review]
make ISO-8859-1 non-removable
Upon a second thought, we don't need to keep charset defaults in the static menu
anymore. Unlike in spring of 2000, we now have a dynamic charset cache
displaying up to 5 charsets. If the static menu doesn't contain the current
document encoding, it'll simply be added. There is no need to keep defaults around.

http://lxr.mozilla.org/seamonkey/ident?i=UpdateCachePrefs

Resummarizing again.
Summary: Customize Character Coding: ISO-8859-1 and intl.charset.default shouldn't respond to the remove button → Customize Character Coding: ISO-8859-1 should be removable from the static charset menu
Created attachment 97886 [details] [diff] [review]
clean-up: remove clutter, Latin-1-related and other dead code

Comment 11

15 years ago
*** Bug 124462 has been marked as a duplicate of this bug. ***
Since this qualifies as "polish", perhaps we could squeeze this change into 1.2.

Having read bug 124462 I'm unclear about what we want to pursue though. I have
patches for both - making ISO-8859-1 undeletable and for removing its special UI
status. If we decide to make it undeletable, we probably need to add some code
to do the same for intl.charset.default and mailnews.view_default_charset...

Comment 13

13 years ago
Changing the summary to convey the two possible options explained in comment #4
and in comment #12. What we currently have is obviously broken - a removable
entry that silently pops back again. Either solution would be better IMHO.

Prog.
Summary: Customize Character Coding: ISO-8859-1 should be removable from the static charset menu → Customize Character Encoding: Decide the status of ISO-8859-1 entry - it should either be truly removable -or- unremovable and grayed out

Updated

13 years ago
Blocks: 254868
Product: MailNews → Core
(Assignee)

Updated

9 years ago
Product: Core → MailNews Core
QA Contact: marina → i18n
Max, Nikolay, can you reproduce?

(has draft patch)
Assignee: nhottanscp → nobody
Status: ASSIGNED → NEW
Flags: needinfo?
Target Milestone: Future → ---
Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/19.0 Firefox/19.0 SeaMonkey/2.16a1 ID:20121019003003 c-c:bd22a204044b m-c:0ff60bfb3442

I haven't tried removing ISO-8859-1 (which, together with UTF-8, is already in my "Active" list in the customization dialog), but I notice that the following, which the dialog does _not_, and never did, list as active, are present in the "View → Character Encoding" menu:

Vietnamese (Windows-1258)
Western (Windows-1252)
Arabic (Windows-1256)

This bug was originally reported for the Mozilla Suite, presumably at a time when Thunderbird didn't yet exist. If the responsible code is in a "forked" file (a file which exists as two copies, one under suite/something and the other probably under mail/something) then I suppose that this bug should also be separated into a Thunderbird bug (in Thunderbird :: Mail Window Front End) and a SeaMonkey bug (in SeaMonkey :: MailNews: Message Display).
Flags: needinfo?
P.S. The two patches are for files somewhere under mozilla/xpfe/... This means that they belong in Core, and may affect the browser (both SeaMonkey-Browser and Firefox).

In the browser window, my "active" charsets are, again, only ISO-8859-1 and UTF-8; but the View → Character Encoding menu also lists "Western (Windows-1252)". Not Vietnamese and Arabic though.

Is XPFE still current though? Or maybe it has been supreseded by Toolkit for some of its uses but not for the choice of character encodings?
P.P.S. I tried removing ISO-8859-1 and it has no effect, neither in the mailer nor in the browser (it is still shown in the menu, and if I reopen the dialog it it still listed on the right side).

I cannot "remove" Vietnamese in the mailer since it appears in the menu without being listed on the right side in the dialog.
(In reply to Tony Mechelynck [:tonymec] from comment #17)
> I cannot "remove" Vietnamese in the mailer since it appears in the menu
> without being listed on the right side in the dialog.

Adding it (with OK) then removing it (with OK) seems to work.
(In reply to Tony Mechelynck [:tonymec] from comment #18)
> (In reply to Tony Mechelynck [:tonymec] from comment #17)
> > I cannot "remove" Vietnamese in the mailer since it appears in the menu
> > without being listed on the right side in the dialog.
> 
> Adding it (with OK) then removing it (with OK) seems to work.

...But if I try to remove all three of Vietnamese, Arabic and Windows-1252, on the third removal all three reappear in the menu.
The character encoding lists can't be customized anymore.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.