"File, Save Page As" changes the source of the page

RESOLVED DUPLICATE of bug 120556

Status

RESOLVED DUPLICATE of bug 120556
7 years ago
2 years ago

People

(Reporter: losepete, Unassigned)

Tracking

Firefox Tracking Flags

(firefox7 affected, firefox8 affected, firefox10 affected)

Details

(Whiteboard: [Moz6-affected])

(Reporter)

Description

7 years ago
User Agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:6.0.2) Gecko/20110905 Firefox/6.0.2 SeaMonkey/2.3.3
Build ID: 20110905145903

Steps to reproduce:

While viewing my hompage in my browser I selected File, Save Page As...


Actual results:

The Save Page progressed fine - but the Saved Page is *not* the same source as the webpage.

For reference my homepage is http://homepage.ntlworld.com/peter.brown35/

Using File, Save Page As... I get lines like this:-

    <meta name="keywords" content="os/2, ecomstation, ecs, system builds, systems preloaded with ecomstation">

    <meta name="description" content="Another website about OS/2 and eComStation operating systems">

    <meta name="author" content="Peter Brown">




Expected results:

The original source looks like this:-

    <meta name="keywords" content="os/2, ecomstation, ecs, system builds, systems preloaded with ecomstation" />

    <meta name="description" content="Another website about OS/2 and eComStation operating systems" />

    <meta name="author" content="Peter Brown" />


So Seamonkey - and, I'm told, Firefox - are changing " />" to ">" when using File, Save Page As...


Of possible interest and definitely related:-

1] If I open my webpage in composer by using File, Edit Page from the browser the source shown in Composer has the same errors as reported above.

2] If I use View, Page Source from the browser the source shown is *correct* - and if I use File, Save Page As... from the View Source window the file is saved correctly, the code is not modified as above.

Comment 1

7 years ago
Works fine with "Web page, HTML only" but "Web Page, complete" shows the described behavior.  Does the same with:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110928 Firefox/7.0.1
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: OS/2 → All

Comment 2

7 years ago
Same behavior with FF8:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0

Updated

7 years ago
Component: General → File Handling
Product: SeaMonkey → Core
QA Contact: general → file-handling
Hardware: Other → x86
Version: SeaMonkey 2.3 Branch → 8 Branch

Updated

7 years ago
Summary: Using Seamonkey Browser "File, Save Page As" changes the source of the page → "File, Save Page As" changes the source of the page
Are you saving as "HTML only" or "complete"?
(In reply to Boris Zbarsky (:bz) from comment #3)
> Are you saving as "HTML only" or "complete"?

See comment #1
(Reporter)

Comment 5

7 years ago
I'm missing something here as I keep seeing the question: Are you saving as "HTML only" or "complete"?

How do I check whether Seamonkey is saving as "HTML only" or "complete"? - there does not seem to be any options In Preferences for this and Seamonkey does not offer a choice when I click "File, Save Page As".
(In reply to Peter Brown from comment #5)
> I'm missing something here as I keep seeing the question: Are you saving as
> "HTML only" or "complete"?
> 
> How do I check whether Seamonkey is saving as "HTML only" or "complete"? -
> there does not seem to be any options In Preferences for this and Seamonkey
> does not offer a choice when I click "File, Save Page As".

After selecting "File → Save Page As…" you see a file chooser. There are two possible versions of the file chooser and I don't know which one you use: I use the XUL file chooser which is not the default (i.e. I have ui.allow_platform_file_picker set to false in about:config) and at the bottom of the file chooser I see a filetype rolldown:

Web Page, complete (*.htm; *.html)
Web Page, HTML only (*.htm; *.html) (default)
Text Files (*.txt; *.text)
All Files (*)

That rolldown is what allows me to select whether to save as "HTML only" or as "Web page, complete".
status-firefox7: --- → affected
status-firefox8: --- → affected
Whiteboard: [Moz6-affected]
Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 SeaMonkey/2.7a1 ID:20111017003001

When saving the same page as "HTML only" and as "complete" I see differences in the saved HTML; I suppose this is also what previous commenters saw:

- The "HTML only" version has /> at the end of unpaired tags, which is normal in XHTML (and this page has an XHTML DOCTYPE line); the other has only >
- The "HTML only" version has more linebreaks and more empty lines.
status-firefox10: --- → affected
Version: 8 Branch → Trunk
The "complete" mode has to serialize the DOM, so it can't preserve distinctions that are not present in the DOM, like the trailing "/".

This is a duplicate, but just resolving wontfix.... if someone wants to look up the original please feel free.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
(Reporter)

Comment 9

7 years ago
(In reply to Boris Zbarsky (:bz) from comment #8)
> The "complete" mode has to serialize the DOM, so it can't preserve
> distinctions that are not present in the DOM, like the trailing "/".
> 
> This is a duplicate, but just resolving wontfix.... if someone wants to look
> up the original please feel free.


I did search for this in bugzilla before opening this bug. I found several similar bugs but not this exact bug. Sorry if it exists and I've missed it - and I have not found any matches at all on my current search. Maybe Bugzilla is having some problem as I am using the same search term that previously returned some close matches?

As for "resolved, wontfix": The browser offers to save the page then changes the source during the save and that is acceptable to you? It is not to me.
The browser offers two save modes:

1)  Exactly what I'm viewing right now (with all images, stylesheets, etc)
2)  The original HTML

You picked #1.
Resolution: WONTFIX → DUPLICATE
Duplicate of bug: 120556
(Assignee)

Updated

2 years ago
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.