In this case, a user's post on a forum was encoded with the wrong character set, resulting in the word 'executable' displaying as 'exÃ©cutable'. Telemetry suggests that useless use or incorrect use of the encoding menu was a big part of its overall use. While the edge case seen here is unfortunate, bug 980904 helps users not waste time with a remedy that's virtually always wrong for the symptoms they are seeing (if the page was labeled as UTF-8 and had no UTF-8 errors, chances are that whatever looks wrong with the page is not a problem that would be remedied by decoding as another encoding). I think we shouldn't roll back that change. > the UI changes from bug 980904 in some circumstances? Henri, do you have any thoughts about reconsidering (In reply to :Gijs (he/him) from comment #4) Then you can put as a hidden field of the form and the browser will fill it in with the actual encoding used. If the script needs to be able to handle non-UTF-8 submission for legacy reasons, it could be changed to copy the value of the form field named '_charset_' into the charset= parameter of the email Content-Type header. If you control the HTML of the form, you can add the attribute accept-charset='windows-1252' on the element. I suggest complaining to the hosting company that they should make the encoding of the HTML page containing the form and the expectations of the form submission handler script match (preferably by changing the script to expect UTF-8). That's a fundamentally bogus configuration. > in latin-1 but they also provide an utf-8 charset on this page. > company in Europe have a incorrectly configured form wich need data encoded Is there a way to bypass this behavior ? here my need, a major hosting

How to change text encoding in chrome