202418 - Data corruption in saved HTML file containing non-breaking space entities

Status: VERIFIED DUPLICATE of bug 119146

(Toolkit :: Downloads API, defect)

Description

[richardtallent]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030304 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030304 Phoenix/0.5

Pages dynamically created by ASP.NET on IIS (.aspx files, have not checked other
common script languages such as PHP or other platforms) containing non-breaking
space entities ( ) are downloaded and viewed correctly, but, when saved
using the "Web Page, complete" option, the nbsp's are replaced in the saved file
with with a literal "Â" character (an actual Latin capital "A" with circumflex,
not HTML entity "Â") and a normal space (character 0032).

Pages ending in "html", "htm", and "asp" do not seem to exhibit this behavior.
I'm not sure if this is because of something special in ASP.NET files or if
something is being done to the file based upon its file extension. I'm also
unsure about any MIME types passed back to the client, but assume ASP.NET passes
back "text/html" unless told otherwise.

This behavior is not exhibited in the Mozilla 1.3 release.

Reproducible: Always

Steps to Reproduce:
1. Create a file "test.aspx" on an IIS server with .NET Runtime v1.1 with the
contents: "<%@ Page %>&nbsp;" (w/o quotes, of course)
2. Open the appropriate URL in the browser.
3. View the source to confirm that "&nbsp;" was sent by the server, not "Â ".
3. Go to File...Save Page As. Use the "Web Page, complete" option.
Actual Results:  
When the saved file is viewed with a standard text editor, the characters "Â "
are embedded in the BODY of the HTML document instead of the expected "&nbsp;".

Expected Results:  
Non-breaking space entities should be preserved on save, not converted to spaces
and certainly not to other strange characters.

This behavior has been observed on both a Windows 2000 workstation and a Windows
XP tablet device. The builds of (the browser formerly known as Phoenix) are
probably not from the same night, but are both after the version .5 release.

A quick guess: the behavior is exhibited when the original file extension does
not match some magic list within Firebird that tells it how to act when
transforming the DOM of the page for saving locally. The usual case is that the
non-breaking space is replaced with a normal space (itself a bug IMHO).

Another potential variable: on my server in this application space, ASPX files
are authenticated (Basic auth), while static files (HTML, etc.) and legacy ASP
files are not. This may help account for the difference in treatment between them.

Comment 1

[Sébastien Delahaye]

WFM w/ Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4a) Gecko/20030411
Phoenix/0.5+
Can you reproduce it with both Phoenix and Mozilla's latest nightlies?

Comment 2

[Sameer D. Sahasrabuddhe]

No access to an IIS server ... reporter, can you up a test script somewhere?

Is the bug still reproducible with a recent build? 20030304 is very old ...

Comment 3

[richardtallent]

I have uploaded a test page at:

http://www.tallent.us/mozillabug202418.aspx

The bug is still there in the latest (2003-05-04) build of Firebird. HTTP 
headers and source are as follows:

HTTP/1.1 200 OKCRLF
Server: Microsoft-IIS/5.1CRLF
Date: Mon, 05 May 2003 15:04:46 GMTCRLF
X-Powered-By: ASP.NETCRLF
X-AspNet-Version: 1.1.4322CRLF
Cache-Control: privateCRLF
Content-Type: text/html; charset=utf-8CRLF
Content-Length: 6CRLF
CRLF
 

Comment 4

[Erik]

Can confirm the problem using Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4b)
Gecko/20030514 Mozilla Firebird/0.6, but this is also present using latest
SeaMonkey!

=> Suggesting to move bug over to Browser / DOM to Text Conversion

Comment 5

[noririty]

*** This bug has been marked as a duplicate of 119146 ***

Comment 6

[Simon Paquet [:sipaq]]

verified.