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.

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.

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.

right, the menu customization is unrelated to message display fallback mechanism.

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.

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

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.

Max, Nikolay, can you reproduce? (has draft patch)

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

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.