120457 - Make it possible to save "dirty DOM" including edited forms and JavaScript variables

Status: NEW

(Firefox :: File Handling, enhancement)

Description

[Heidi Strayer]

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.

Comment 1

[Asa Dotzler [:asa]]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

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.)

Comment 3

[Asa Dotzler [:asa]]

->file handling

Comment 4

[Boris Zbarsky [:bzbarsky]]

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

Comment 5

[Bill Law]

Future-ing, at least till we get more info

Comment 6

[Alan]

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.  

Comment 7

[R.K.Aa.]

dup of bug 115328?

Comment 8

[Boris Zbarsky [:bzbarsky]]

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?

Comment 9

[Alan]

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.  

Comment 10

[Boris Zbarsky [:bzbarsky]]

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

Comment 11

[Ed Catmur]

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.

Comment 12

[Ed Catmur]

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)

Comment 13

[Boris Zbarsky [:bzbarsky]]

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

Comment 14

[Alan]

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). 
 

Comment 15

[Jesse Ruderman]

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 ***

Comment 16

[Alan]

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.  

Comment 17

[Boris Zbarsky [:bzbarsky]]

> 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 ***

Comment 18

[Alan]

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

Comment 19

[Boris Zbarsky [:bzbarsky]]

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....

Comment 20

[rbs]

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...

Comment 21

[WADA:World Anti-bad-Duping Agency]

Attachment: javascript to view script-generated HTML source image

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.

Comment 22

[Mijail]

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.

Comment 23

[Brian 'netdragon' Bober]

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

Comment 24

[Brian 'netdragon' Bober]

Sorry, typo.

Comment 25

[Brian 'netdragon' Bober]

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

Comment 26

[moz bug]

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.

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 29

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit BugBot documentation.