User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20140203105410 Steps to reproduce: Viewed the source of a UTF-8 encoded/served page, and checked the encoding in the View -> Character Encoding submenu. The website tested isn't publicly available, but the same issue can be seen with theverge.com. Actual results: Selected encoding was Windows-1252. Expected results: Selected encoding was UTF-8.

Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/746e7c151de2 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111101 Firefox/10.0a1 ID:20111101015315 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/d9cc2539a85d Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111031 Firefox/10.0a1 ID:20111101043415 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=746e7c151de2&tochange=d9cc2539a85d Regressed by:Bug 482921

Pages that declare the encoding on the HTTP level are not affected. Pages that declare the encoding in <meta> are decoded correctly, but the menu is initialized incorrectly.

Same issue with an Atom feed served as UTF-8 with no meta tag though - view-source shows the actual feed source (not the source of Firefox's generated page) but has Western-1252 selected in the page encoding menu. In that case though there's a separate bug in dealing with its application/atom+xml IANA media type: https://bugzilla.mozilla.org/show_bug.cgi?id=978464