253205 - When a pages is saved, Firefox changes all   to "Â" followed by a space.

Status: RESOLVED EXPIRED

(Firefox :: General, defect)

Description

[HPD]

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&nbsp;</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&nbsp;
10:00 AM&nbsp;

Example from a drop down list:
Business
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Council
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Council
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Directory
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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+

Comment 1

[Oleg Sidletskiy]

*** Bug 253206 has been marked as a duplicate of this bug. ***

Comment 2

[Tomi "BGT" Mäntylä]

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.

Comment 3

[Hallvard B Furuseth]

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 "&nbsp;"
to its UTF-8 equivalent?  That sounds buggy.  I note that the current
version of the test page contains several "&nbsp;" but no raw UTF-8
non-breaking spaces.

If you really meant meant "non-breaking space" when you said "&nbsp;",
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.

Comment 4

[Graham Klyne]

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

Comment 5

[Gervase Markham [:gerv]]

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/

Comment 6

[Gervase Markham [:gerv]]

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.