Created attachment 568957 [details] cryptic.gif User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 Build ID: 20110928134238 Steps to reproduce: Upgraded from FF 5 to FF 7.0.1. Actual results: Suddenly many websites show dashes and quote signs as boxes with numbers. Until FF 5.0 everything was displayed fine. The fonts contain these signs. Playing with "character encodings" option changes only for worst. Happens in SAFE MODE too. I run MacOSX 10.6.8! Sample URL: http://www.idea.de/nachrichten/detailartikel/artikel/kein-weltuntergang-radioevangelist-camping-schweigt-1.html Expected results: Display correctly all characters like in FF 1.5 to FF 5.0 ...
Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20100101 Firefox/7.0.1 works for me on Windows Please test in save mode and with new profile. http://support.mozilla.com/de/kb/Allgemeine%20Fehlersuche http://support.mozilla.com/kb/Basic%20Troubleshooting http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting
The site WFM in both 7.0.1 and Nightly (10.0a1) on OS X 10.6.6. By way of background, I notice that the http://www.idea.de/ page mentioned is in fact faulty: the page declares its encoding as ISO-8859-1, but is in fact using Windows codepage 1252 (which matches the ISO codepage *except* that it includes a number of printable characters in the 0x80..0x9F range, which are control codes in ISO). The problem characters in the screenshot are precisely the ones that are present in the Windows codepage but not in the ISO encoding that the page claims to use. As such, it would be strictly _correct_ to display missing-glyph boxes or some such representation in place of the intended quote marks, etc., on that page; this would accurately represent the data according to the charset it declares. However, it seems that we (and other browsers) generally treat an ISO-8859-1 declaration as actually being Windows CP1252, as there are no doubt many such pages out there on the web with incorrect charset metadata. I don't know why this is behaving differently for the reporter here.
> However, it seems that we (and other browsers) generally treat an > ISO-8859-1 declaration as actually being Windows CP1252 Doesn't HTML5 require exactly this?
(In reply to j.j. from comment #3) > > However, it seems that we (and other browsers) generally treat an > > ISO-8859-1 declaration as actually being Windows CP1252 > > Doesn't HTML5 require exactly this? So it does. So the interpretation of those bytes as quote marks, etc., is correct per spec. This doesn't alter the fact that the page is lying about its charset, but HTML5 decided this particular error was so prevalent that browsers are expected to support it. (The HTML5 spec even acknowledges that "The requirement to treat certain encodings as other encodings according to the table above is a willful violation of the W3C Character Model specification, motivated by a desire for compatibility with legacy content.") The real question here, though, is still why the original reporter isn't seeing the expected (Windows-1252) interpretation of the (ISO-8859-1-tagged) page, when this is working as expected for other users.  http://www.whatwg.org/specs/web-apps/current-work/multipage/parsing.html#determining-the-character-encoding
As said in the first post the errors also showed in SAFE MODE. With a NEW PROFILE the errors disappeared. I did some digging and found: intl.charset.default;ISO-8859-15 I resetted to: intl.charset.default;ISO-8859-1 Now the boxes disappeared and the quote signs appeared again. Everything runs as expected. Sorry for this false bug report, and Thanks!
The resolution is INVALID then (worksforme is for not traceable issues).