802033 - Remove UTF-16* from the fallback encoding UI

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[Henri Sivonen (:hsivonen)]

Steps to reproduce:
1) Open preferences.
2) Choose the "Content" pane.
3) Click the "Advanced…" button in the "Fonts & Colors" section.
4) Open the pop-up menu labeled "Default Character Encoding".
5) Scroll towards the end of the menu.

Actual results:
The menu has items UTF-16, UTF-16LE and UTF-16BE. Letting the user actually choose any of these options would break many Web pages beyond recognition. As of the fix for bug 599320, these three choices are no longer honored.

Expected results:
Expected the menu not to have items for UTF-16, UTF-16LE or UTF-16BE.

Comment 1

[Dão Gottwald [:dao]]

What about View > Character Encoding > More Encodings > Unicode?

Comment 2

[[e-mail]]

As far as I can tell it's an all-or-nothing flag. I found the following menus that include UTF-16*:
Browser View Character Encoding
Browser Default Character Encoding (intl.charset.default)
Mail Default Character Encoding (mailnews.view_default_charset)
Mail Default Character Encoding (per folder)
Mail View Character Encoding (except UTF-16?E, except on the app menu)
Message compose uses a different list that excludes UTF-16*.
Another list is used in SeaMonkey Composer but it seems to broken :-(

Comment 3

[Henri Sivonen (:hsivonen)]

(In reply to Dão Gottwald [:dao] from comment #1)
> What about View > Character Encoding > More Encodings > Unicode?

I’d be happy if we could remove UTF-16* there, too, but I’m not sure how harmless that would be in term of user impact with radically bogus pages. In other words, I don’t know how widespread it is to have unlabeled and BOMless UTF-16 content out there.

Note that UTF-16 in the View menu will become less necessary once I fix bug 716579.

(In reply to [e-mail] from comment #2)
> Browser View Character Encoding

Having UTF-16* there *might* be something we can’t get rid of. But as I said above, I’d be happy if we removed it there and discovered it was OK.

> Browser Default Character Encoding (intl.charset.default)

Does not make sense to have UTF-16* there.

> Mail Default Character Encoding (mailnews.view_default_charset)

Nor there.

> Mail Default Character Encoding (per folder)

Nor there.

> Mail View Character Encoding (except UTF-16?E, except on the app menu)

I don’t know the mail situation well enough to say if this is needed.

> Message compose uses a different list that excludes UTF-16*.

Hooray.

Comment 4

[Masatoshi Kimura [:emk]]

UTF-16* is not suitable charsets for MIME, so I don't think mailnews needs them.

Comment 5

[Henri Sivonen (:hsivonen)]

(In reply to Dão Gottwald [:dao] from comment #1)
> What about View > Character Encoding > More Encodings > Unicode?

Let’s zap UTF-16 there, too. The proposed patches for bug 234628 make it impossible to manually change away from UTF-16 for security reasons (http://hsivonen.iki.fi/test/moz/never-show-user-supplied-content-as-utf-16.htm) and it would be bad to be able to change to UTF-16 if you can’t switch away.

Comment 6

[Henri Sivonen (:hsivonen)]

Maybe bug 805374 will fix this as a side effect.

Comment 7

[Henri Sivonen (:hsivonen)]

The part of bug 805374 that landed already fixed this.