hsivonen

Hare is presented with the expectation that it would be included in Linux distros. With that framing, criticism on matters that are relevant to distro-included software is indeed relevant.

Your example is not an example of actual Firefox failure mode: If I encode your text as ISO-8859-1 and run chardetng on the bytes, it says ISO-8859-2. It’s generally unlikely that chardetng would misdetect ISO-8859-2 Polish as windows-1252.

When you claim that something isn’t working for you (and it’s completely plausible that you have encountered a case where chardetng doesn’t work for you), it would be polite to post the actual failure and not something that’s not an actual example of failure.

Have you encountered concrete cases of failures with Cyrillic single-byte encodings (where the letters fail; there are cases where box drawing characters fail due to preferring letters over box drawing)?

As a matter of usage and severity of failure mode, East Asian languages are very much the main concern. Japanese specifically is the primary motivator for keeping the feature in any form.

If there's more elaborate UI surface in order to address Latin-script cases where autodetection fails (I estimate 1% failure rate for Polish), it risks getting the whole thing removed completely even for Japanese users (as happened with the hamburger menu entry point in Firefox when the hamburger menu was rewritten, as happened in Chrome previously, and as happened with Safari for iOS in the sense of the menu never making it to iOS).

> Basically, when you need to read some very old Japanese site where their encoding is pretty non standard, you are screwed.

As it happens, the primary reason why the single menu item remains instead of an override being totally gone is usage in Japan. (Many people in this thread comment as if Firefox had done what Chrome did: complete removal of override as you note.) The remaining menu item is pretty accurate for its primary use case, which is dealing with Japanese legacy sites that misdeclare their encoding. (There is one exception: If the page declares UTF-8 but is actually ISO-2022-JP, then you don't have recourse.)

After the submenu was replaced with a single item in August, how many times have you 1) encountered Polish mojibake and 2) the single item wasn't able to fix it?

In cases where Chrome autodetects, Firefox autodetects, too.

In the cases where you'd use the remaining menu item in Firefox, Chrome offers no recourse (apart from extensions).

> A complicating factor on the telemetry is that both this new "guess" option and its predecessor list are/were in the menubar View menu and have no way to be accessed through the "hamburger," so there wasn't a default-visible way to get to this functionality for Windows and Linux users.

The collapsing the submenu of the View menu into a single item shipped in Firefox 91. The submenu was removed from the hamburger menu in Firefox 89.

This order of changes was unfortunate. If I had gotten the single-item design done sooner, perhaps the rewritten hamburger menu would have kept the single item instead of removing the entry point altogether.

Notably, the single menu item in Firefox does what it says on this page, so this page doesn't demonstrate why having just one menu item is a problem.

> Speaking as someone whose native language is non-Latin-based, I think it was a very bad idea.

Bad in principle or bad because you've personally encountered pages where the menu item doesn't work but macOS Safari's submenu does?

The crate linked to from the comment you replied to uses RUSTC_BOOTSTRAP for a non-SIMD reason: To allow Firefox to be built with somewhat old rustc.

Firefox no longer updates its MSRV in sync with Rust release trains. I’d be happy to remove this particular RUSTC_BOOTSTRAP if we decided to increase Firefox’s MSRV (currently stuck at 1.47.0).