This setting is only meant for 8 bit encodings that are locale dependent.
The intl.charset.default pref is removed and intl.charset.fallback.override is now being used.

See:

• bug 910192 - Get rid of intl.charset.default as a localizable pref and deduce the fallback from the locale

Please do not comment in bug reports
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

This was an intentional change to have the fallback encoding for legacy content be determined by the locale of your Firefox.

The old "intl.charset.default" preferences no longer exists.

There is a new preference named "intl.charset.fallback.override" but if you set it to UTF-8, that is ignored. The rationale for this is UTF-8 is not a legacy encoding.

What is the reason for using utf-8 as the fallback encoding for legacy content? Is this for content not delivered from a webserver (so there is no content type header)?

References to the bug tracking system:

• 910192 – Get rid of intl.charset.default as a localizable pref and deduce the fallback from the locale (change made in Firefox 28)
• 967981 – Provide some way for addons/prefs to control the default fallback character set (closed)

About the bug tracking system:

It's generally not helpful to add comments to closed bugs, but you can register on the Bugzilla site and create a new bug making the case for having this option.

• https://bugzilla.mozilla.org/enter_bug.cgi (you may want to mention the two earlier bugs)
• https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

It's true that UTF-8 is not a legacy encoding. However, legacy pages are those that do not declare their encoding. While dealing with sites (internal intranet and smaller internet) that do not declare an encoding, I want to assume UTF-8.

This gives me the option of notifying the authors that their pages/sites don't specify the encoding as they should. I want to see many occurrences of U+FFFD REPLACEMENT CHARACTER instead of junk in an inferred legacy encoding.

Sounds like time to file a new bug.

As a temporary workaround, maybe there's an extension which lets you override Firefox's normal encoding selection. (Unfortunately, a page reload might be required.)

Thank you -- I think I'll file a new bug for this as per your suggestion.

I posted comments to the two bugs that you linked in your earlier message, but I don't think I was as constructive or respectful as I should have been with the tone of my messages. I was quite unhappy upon finding this change in Firefox 28 and shouldn't take it out on Mozilla developers who mean well.

I have the same problem: https://support.mozilla.org/en-US/questions/1001030?esab=a&s=&r=0&as=s

The pages served on intranet do not declare their encoding. With setting UTF-8 this was not a problem. Now, text is completely garbled. This is especially painful as we're working in a mixed language/script environment.

Hi DKARSEM, I haven't looked up the bug to see what is planned for this issue.

Hopefully you can fix this in your intranet software. It could be as simple as one global change in your web server configuration. Usually your web server will announce its identity in the Response headers. To view those, open Firefox's web console (Mac: Command+Alt+k, Windows: Ctrl+Shift+k), load a page on your intranet, and click one of the links in the console to view the headers. With that knowledge, you probably can find the steps for your internal webmaster to set the default character set so that individual applications and pages do not need to be updated.

Actually many web-interfaces of old devices made by english-speaking countries just output utf-8 characters without declaring a charset.

I don't understand why "UTF-8" is ignored in "intl.charset.fallback.override". That is unmeaning and only brings troubles to those developers who need it.

A default "UTF-8" encoding is very convenient for those non-english developers when they just want to do some little tests in a html file.

And most old local websites declared a local encoding for their users without any problems.

Just like google removes "http://" from address bar, which makes copying the domain name from an entire url become much troublesome, a useless small modification may make people choose another product.

Hi wong369, I don't have an answer to the original problem, but you may have noticed that Firefox also removes http:// from the address bar. There is a preference in about:config to bring it back if you prefer (I prefer): switch browser.urlbar.trimURLs to false.

• https://developer.mozilla.org/Mozilla/Preferences/Preference_reference/browser.urlbar.formatting.enabled
• https://developer.mozilla.org/Mozilla/Preferences/Preference_reference/browser.urlbar.trimURLs

Thank jscher2000, I have already switched the browser.urlbar.trimURLs preference, and that's why I finally turn back to firefox after using chrome for several years. I mentioned that just because I hoped firefox could keep being customizable .