User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.6) Gecko/20040210 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.6) Gecko/20040210 Firefox/0.8 When certain web pages are saved locally as type "Web Page, complete," Firefox changes all to "Â" followed by a space (xC2 xA0). For example, <b><font color=black>8:30 AM </font></b> becomes <b><font color="black">8:30 AMÂ </font></b> Reproducible: Always Steps to Reproduce: 1. Go to http://www.mychurchevents.com/calendar/calendar.aspx?ci=L6J4J4I3F0K5I3G1 2. Save the page as type "Web Page, complete." 3. Load the saved page Actual Results: 8:30 AMÂ 10:00 AMÂ Example from a drop down list: Business Â Â Â Â Â Council Â Â Â Â Â Directory Â Â Â Â Â Facilities Expected Results: 8:30 AM 10:00 AM Example from a drop down list: Business Council Council Directory Facilities Use The page is saved correctly when the "Save as type:" is "Web Page, HTML only". This bug was reproduced by another person using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040715 Firefox/0.9.1+
*** Bug 253206 has been marked as a duplicate of this bug. ***
Also tags such as <meta http-equiv="Content-type" content="text/html; charset=iso-8859-1" /> get the /-character stripped off. <meta http-equiv="Content-type" content="text/html; charset=iso-8859-1"> which causes problems with validators.
The test URL has HTTP header "Content-Type: text/html; charset=utf-8". In UTF-8, non-breaking space has the reported encoding: xC2 xA0. In iso-8859-1, that encoding means "Â" + non-breaking space - almost as reported. I expect the reporter has iso-8859-1 or a superset like Windows-1252 as Edit/Preferences/General/Languages/Default Character Encoding. Inserting <meta http-equiv="Content-type" content="text/html; charset=iso-8859-1"> in the saved file merely confirms that. To display the saved file correctly, insert charset=UTF-8, modify the browser's default character encoding, or try an extension like the Right Encoding extension. I can't test this on Windows and the test URL has changed anyway, but: Reporter, did yo really mean Firefox changed the HTML sequence " " to its UTF-8 equivalent? That sounds buggy. I note that the current version of the test page contains several " " but no raw UTF-8 non-breaking spaces. If you really meant meant "non-breaking space" when you said " ", and the non-breaking spaces were represented as UTF-8 byte sequences already, then Firefox didn't change the saved page - it just didn't know which character encoding to use when you loaded the saved file, since files have no Content-Type: headers. I don't know if Windows files can be marked with their character encoding in some other way, without changing the file contents. Firefox could modify the file contents and insert a http-equiv statement. I really hate it when IE changes files I download in similar ways without asking me, though. Maybe such changes should be an option. However, maybe that lives in a different bugzilla report.
I found a similar problem with –. View URI: http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050217/ This looks fine when viewed online, but when saved as a webg page, and then re-examined from the local copy, occurrences of – have been replaced by three wierd characters (?replaced by UTF-8 equivalent - just a wild guess?). E.g. see headings for sections 5.4 and 6. Using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.