1813217 - Provide the Repair Text Encoding function in Fenix

Status: NEW

(Firefox for Android :: General, enhancement)

Description

[Jonathan Almeida [:jonalmeida]]

From github: https://github.com/mozilla-mobile/fenix/issues/16121.

What is the user problem or growth opportunity you want to see solved?

Prior to Fenix, Firefox for Android provided an option to set preferred encoding for webpages, although it was hidden by default, and users are able to enable it in the Settings. But since Firefox Daylight is released, this feature is disappeared. However there are still have some websites have neither specific locale language nor content encoding on their webpages and HTTP headers.

How do you know that this problem exists today? Why is this important?

Without this feature, some websites are unable to display correctly with specified encoding, and display as mojibake.

Who will benefit from it?

Anyone who encountered such pages on Fenix.

┆Issue is synchronized with this Jira Task

Change performed by the Move to Bugzilla add-on.

Comment 1

[Henri Sivonen (:hsivonen)]

I think this issue as titled (configurability of the fallback encoding) is a clear WONTFIX. However, I think it could be reasonable to offer the same functionality that's available on desktop. I'm retitling this accordinly.

Some notes about replicating the desktop feature (in the View menu and available as a toolbar button via Customize Toolbar…):

• It doesn't make sense to decide whether to offer the feature by taking a global look at telemetry: When Latin-script locales participate in telemetry, the global result is that feature usage is extremely rare. The relevant thing to observe is that on desktop, looking at what proportion of distinct telemetry submitters use the feature at least once over a given time period, Japan totally stands out with Taiwan up next. The decision should be whether the Japan use case is worth addressing and, if it is, letting other locales, at least non-Latin-script ones, have the feature, too.
• On desktop, I don't have any particular telemetry number threshold for considering the Japan use case worth addressing. Telemetry showed that Japan stands out, and instead of having a particular threshold, I observed that people really care about reporting bugs about this topic in the Japan/Japanese context.
• The menu item should be called "Repair Text Encoding".
• When the page is loading, the menu item should be disabled.
• When the page load completes, the menu item should be enabled if, and only if, the mayEnableCharacterEncodingMenu property of the frontmost top-level docshell is true.
• Invoking the menu item (when enabled) should call forceEncodingDetection() on the frontmost top-level docshell and then immediately tell it to reload via nsIWebNavigation.reload(nsIWebNavigation.LOAD_FLAGS_CHARSET_CHANGE).

Since the engine side is already there, as noted in the last two bullet points above, I'm moving this to a component that better covers Fenix front end decisions.

Comment 2

[Tom25519]

In Fennec, it also called "Character Encoding" in 3-dot menu.