If I dynamically create a web page and do a "Save As", I get the previous contents saved and not the source for the page currently being displayed. This is crucial for our application because it is necessary for users to save this dynamically created page for later reuse (we basically use it as a physically portable state file for a non-server based application.) View source also does not display the dynamically generated source so we can't direct our users to use this mechanism for saving the contents either.

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

Reopening. This seems like a different problem to me. Heidi, let me see if I understand correctly. You want Mozilla to save the current state of the DOM as opposed to the original source? (Note that this is the exact opposite of what most users want saved on most pages.)

->file handling

Heidi, could you please clarify the exact situation here? We can't fix this bug until we know what the problem is...

Future-ing, at least till we get more info

This seems to be the same problem i have been having since just after the 0.99 milestone. Save As, Web Page Complete no longer works for pages i have generated using javascript. about the same time something changed in the handling of wyciwyg:// links and they were no longer shown. Try using one of the bookmarklest here: http://matrix.netsoc.tcd.ie/~horkana/dev/javascript/index.php#split prefereably the one that splits the screen and shows two documents side by side. Then try and save as web page complete (from either the file menu or by right clicking it doesnt matter) and nothing will happen, the save as dialog will not even appear. im using Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020322 and have been having this problem since roughly just after the 0.99 milestone.

dup of bug 115328?

Not clear, since reporter hasn't bothered to clarify exactly what the bug is. Heidi, could you please clearly explain exactly how you're saving (web page, complete? Or html-only?) and what _is_ saved as opposed to what _should_ be saved?

The comments in bug 137784 say that they want exactly the opposite of what we want. They want the original page even though it has been modified by javascript. If bug 137784 is a duplicate of 115328 and this bug is the opposite this bug cannot be a duplicate. Would it be correct to say bug 115328 blocks this bug? Anthor example of why being able to save a javascript generated page is useful. http://bugzilla.mozilla.org/show_bug.cgi?id=32627#c11 The second bookmarklet mentioned in the above link will generate a new page containg all the images linked to from the current page, then you can (or at least you used to be able to) Save As Web Page Complete and save a whole gallery in one go. In this case the original page is entirely differnt from the generated page, and I certainly dont want to save the orginal.

There could be various issues associated with the fact that wyciwyg:// uris do not implement nsIURL.

This is closely related to bug 63892. Given a 'View Live Source' command, one could go View->Live Page Source and Save As from there.

Workaround: 1. Open page in DOM Inspector 2. Right click on the root node, choose "Copy XML", fire up your favorite text editor, paste, save (see bug 141341)

Ed, how can you possibly know what this is related to, if Heidi has not even bothered to explain WHAT THE PROBLEM IS?

To: Boris Zbarsky Ed seems to understand either the explanation I (Alan) or Heidi has given. It is clear to me that my problem is the same as problem Heidi is having. I will try and explain it further if you think it is necessary (ask me offlist).

This bug is a dup of bug 158598, "Save Page As fails on pages with no title, filename or URL e.g. JavaScript generated popup windows". Save As Complete and Save As HTML-only both work if the document.written page has a title. The file picker does not appear if the page does not have a title. *** This bug has been marked as a duplicate of 158598 ***

Please dont mark older bugs as duplicates of newer bugs. Am i not at least entitled to a proper explanation on why this bug should be closed in favour of the newer bug.

> Am i not at least entitled to a proper explanation on why this bug should be > closed in favour of the newer bug. The newer bug has a patch. So marking it duplicate of this one, transferring the patch (and reviews), etc, would be a pointless exercise in idiocy. *** This bug has been marked as a duplicate of 158598 ***

okay, patches are a good reason i just wish you had said that in the first place "etc, would be a pointless exercise in idiocy." i wish you had not said that. i am trying to help in my own way, i dont think i gave you any cause to be condescending, if my words were poorly choosen then i regret that but i was in no way trying to annoy you i just like to know the reasons for a bug being closed. Marking as verified

I'm sorry if you perceived that as me being condescending. It was not meant to be, and I did not mean to imply in any way that you would support "transferring the patch (and reviews), etc," from that bug to this one....

Re-opening. It is unfortunate that hedi didn't explain the bug despite the repeated calls for clarification in comment 2 and comment 3. Consequently, the bug drifted away from its original intention, and was marked as duplicate of an unrelated bug. I am having the very same problem as originally reported. Basically, imagine that you have a page where users can interact with JavaScript and modify the page in arbitrary ways, i.e., two users are likely to end up with different contents after a while. Then, they take a coffee break or something, hoping that they will continue later. When they return, the power supply has gone off, they have lost all what they were doing... So the idea of the bug, as originally reported, is to indeed allow users to save the current page, with its 'dirty' DOM yes, so that loading the saved page brings users exactly where they were. This is very different from other bugs. Yet, in my opinion, all this much touted world of DOM+JS is incomplete without such a modern function to save the page with its 'dirty' DOM in addition to the classic option of saving the page with the clean DOM (i.e., just copy from the cache). This bug has serious implications (re:web services). Also, an intrinsic benefit is the fact that pages are saved on the user's side, meaning that different users can end up with a variety of scenario without further need for a complex tracking system (with the security issues and etc). I am even hoping that there could be a document.save() JS function, to bring up the filepicker, so that applications can show: <button onclick="document.save()">Save</button> remending users to periodically click-and-save what they are doing...

SInce DOM-Object.innerHTML is already supported, HTML source data can be obtained by document.getElementsByTagName("html")[0].innerHTML. Attachement is a JavaScript(javascript:....) to display it in new browser window(HTML source image under HTML element only. No lines before <html> such as DOCTYPE declaration.) Please note that this script generates HTML to view script-generated HTML source, HTML source itself in the new window is not a real HTML source of original script-generated HTML - "<",">","&" in original script-generated HTML source is replaced by "&lt;","&gt;","&amp;" respectively and "\n" is replaced by "<br>". Please paste contents of attached file to URLbar and try it.

The proposed solutions of copy&pasting from the "view source" window, the DOM inspector, or the attached javascript, don't really work. As an example, go to www.windguru.cz. There you'll see a javascript-created table which contains some little images. Doing the "view source" trick (and the others) does save the generated HTML... but breaks the images. Ideally, there should be a way to "Save as" with a "complete HTML" format: HTML file with the accompanying images/whatever.

WADA: afaik, innerHTML (due to it's quirks) won't work safely in all cases, and it's better for us to use the XPCOM back-end for this. DOM level 3 might allow a safer way to do this from a javascript. I seemed to have a different issue, where both generated source and non-generated source appeared when I saved. "Save as" should not save generated content by default, but it would be nice for the work I do here at Eyewonder if we had the option. Having this in viewsource would also be good for what I do. --> Default owner

Sorry, typo.

By the way, the issues I mentioned in comment #23 are: Bug 179490 - Save As Web Page Complete saves both the JavaScript and output of the JavaScript Bug 60426 - Allow users to choose between generated and source html in view-source

I would have thought the basic function of Save As is to save a copy of what is on the screen to have a record of that information. This should not be recreated dynamically next time I open the saved page, very likely with differing results. If, for some techinical reason I want the source that created the display rather than the display I would use ViewSource or maybe reload the page with javascript disactivated. But this would not be normal browser behaviour. I agree with OP, this is a bug.