1479364 - "View > Text Encoding" is disabled on some pages (for example BMO) despite some non-UTF-8 content shown in a frame

Status: RESOLVED DUPLICATE of bug 1468003

(Core :: DOM: HTML Parser, defect)

Description

[Jorg K (CEST = GMT+2)]

"View > Text Encoding" is disabled on some sites, for example BMO.

Yesterday I submitted a patch that had some umlauts in it, on encoded in windows-1252, another one in UTF-8, attachment 8995823 [details] [diff] [review]. Click on [details] and see that the encoding menu is disabled in that page.

It works OK on the HG page:
https://hg.mozilla.org/comm-central/rev/9dc3759e20aa2f226a6836f6f1f4d3ad7ddfb635#l3.13

Is that intentional?

Comment 1

[Masatoshi Kimura [:emk]]

Workaround: Right clink on the attachment frame and select "This frame" > "Show only this frame" from the context menu.

Comment 2

[:Gijs (he/him)]

We intentionally disable it for pages that successfully parse as utf-8, I think. See bug 980904. I don't know if that applies to your patch, even if you see gobble-dy-gook. Henri can comment further about what we should do here when he gets back, but even if we want to fix this it probably has more to do with parser support for dealing with frames than it does with the button itself.

Comment 3

[Jorg K (CEST = GMT+2)]

Attachment: mixed-encoding-text.txt - file with UTF-8 and windows-1252 content

I wasn't aware of bug 980904 and don't want to study the ~55 comments in detail. However, this one caught my eye (980904 comment #11):
===
> ..., but since encoding menu doesn't hurt and have some,
> even if *unlikely use*, why not to keep it always enabled?
Encoding menu is a well-known self-XSS attack vector (especially ISO-2022-JP). I'd like to disable it as much as possible.
===

The emphasis is on "unlikely use", like in my case.

I think disabling a menu element without a discernable reason makes for a really bad UI. Maybe some UI people should have been involved in that discussion. It would have been preferable to pop up the charset menu, showing the preselected Unicode entry (perhaps with a tooltip or so) and disabling choosing anything else.

All that said, what was implemented doesn't work correctly. In the case of my patch, the page in UTF-8 contains a windows-1252 character in a frame, and the UI doesn't allow me to view that correctly. In the patch had that single character way down and you had to scroll to see it, so maybe it's more apparent with this text attachment.

Comment 4

[Jorg K (CEST = GMT+2)]

Right, open this link https://bugzilla.mozilla.org/attachment.cgi?id=8996016&action=edit and you cannot force it to display the second line correctly. You need to be aware of the workaround given in comment #1 (Show only this frame).

Comment 5

[Henri Sivonen (:hsivonen)]

(In reply to Jorg K (GMT+2) from comment #0)
> Is that intentional?

It is. See my comments on bug 1468003 for details.

Additional thought: Back when the change was made, we didn't have a good way to track if an HTML document has encoding errors. Now we have, so in principle we could now distinguish between ASCII-only advertising iframes from non-advertising iframes containing non-ASCII. At this point, I'm reluctant to add elegance to the encoding menu behaviors, though. Chrome and Edge have gotten rid of the menu, and I think our trajectory should be towards getting rid of it instead of making it address more use cases.