User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 After saveing the page the xhtml end slashes on single tages are removed. In this expample the file is saved as: <meta name=".." content=".."> This should be: <meta name=".." content=".." /> This gives a page which isn't correct xhtml any more!! The show source shows the correct page. Als wget will give you the correct page. I checked also the version "Mozilla 1.4b" but got the same behaviour. Reproducible: Always Steps to Reproduce: 1. Save the page with mozilla 2. wget http://www.xs4all.nl/~marceln/mozilla-save-bug.html 3. Use "tidy" to verify both pages. The real page is ok. The saved page not! Actual Results: $ tidy -e -asxhtml mozilla-save-bug.html line 2 column 3 - Warning: <meta> element not empty or not closed line 3 column 3 - Warning: <meta> element not empty or not closed Info: Doctype given is "-//W3C//DTD XHTML 1.0 Transitional//EN" Info: Document content looks like XHTML 1.0 Transitional 2 warnings, 0 errors were found! Expected Results: The saved version should be bytewise identical!

I think this is expected behavior. If you save the file as "HTML Only" you will get the XHTML out. When you save as "Web page, complete" you get the parsed output. The file is being sent as HTML (text/html), so the ending slashes are extraneous noise that is filtered out (and the file gets saved as proper HTML, though with a bad doctype in this case). Since "web page, complete" has to fix all the links up, the output is not meant to be the same as the original source.

Invalid, since the save is done as "page, complete".

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

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

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

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

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

(In reply to comment #7) > > *** This bug has been marked as a duplicate of 120556 *** Hmm. Bug 120556 comment 22 instructed somebody seeing this issue to file a new bug under DOM to Text Conversion if their document was served as text/html, so marking this bug as a duplicate of that one seems circular. In general, I think that I understand the argument for marking this as INVALID, but I honestly don't feel that it's realistic. Yes, in a perfect world all XHTML documents would be served as application/xhtml+xml (at least to browsers that understand that format), but MSIE's rejection of such documents makes the situation far more complicated. Not every webpage author trying to make the transition to XHTML has the knowledge and the permissions to configure the server to send different mime-types to different browsers! Also, note that the "Save as... complete" option is no longer even given for XHTML documents: XHTML has been cut from isDocumentType() in contentAreaUtils.js. Until that changes, the only way to save an XHTML page as "Web Page, complete" is to serve it as text/html. It's even possible that this bug is part of the reason that "Save as... complete" was disabled for XHTML; I'm really not sure. So if this bug _is_ legitimately invalid, I'd love to hear which bug(s) I should be voting for (and possibly working on) to make this possible.