Open
Bug 120457
Opened 23 years ago
Updated 2 years ago
Make it possible to save "dirty DOM" including edited forms and JavaScript variables
Categories
(Firefox :: File Handling, defect)
Firefox
File Handling
Tracking
()
NEW
People
(Reporter: strayer, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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•23 years ago
|
||
*** This bug has been marked as a duplicate of 40867 ***
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Comment 2•23 years ago
|
||
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.)
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 3•23 years ago
|
||
->file handling
Assignee: asa → law
Status: UNCONFIRMED → NEW
Component: Browser-General → File Handling
Ever confirmed: true
QA Contact: doronr → sairuh
Comment 4•23 years ago
|
||
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
Target Milestone: --- → Future
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?
Comment 8•23 years ago
|
||
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.
Comment 10•23 years ago
|
||
There could be various issues associated with the fact that wyciwyg:// uris do
not implement nsIURL.
Comment 11•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → DUPLICATE
Comment 16•22 years ago
|
||
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.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 17•22 years ago
|
||
> 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 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → DUPLICATE
Comment 18•22 years ago
|
||
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
Status: RESOLVED → VERIFIED
Comment 19•22 years ago
|
||
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•22 years ago
|
||
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...
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Updated•22 years ago
|
QA Contact: sairuh → petersen
Comment 21•21 years ago
|
||
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 "<",">","&" respectively and "\n" is replaced
by "<br>".
Please paste contents of attached file to URLbar and try it.
Comment 22•21 years ago
|
||
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•19 years ago
|
||
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
Assignee: law → file-handling
Status: REOPENED → NEW
QA Contact: chrispetersen → ian
Summary: "Save As" of a Javascript generated page does not save the displayed source. → "Save As" of a Shold be able to save generated content of a page
Comment 24•19 years ago
|
||
Sorry, typo.
Summary: "Save As" of a Shold be able to save generated content of a page → "Save As" should optionally allow to save generated content of a page
Comment 25•19 years ago
|
||
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•18 years ago
|
||
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.
Updated•18 years ago
|
Summary: "Save As" should optionally allow to save generated content of a page → Make it possible to save "dirty DOM" including edited forms and JavaScript variables
Updated•15 years ago
|
Assignee: file-handling → nobody
QA Contact: ian → file-handling
Updated•8 years ago
|
Product: Core → Firefox
Target Milestone: Future → ---
Version: Trunk → unspecified
Comment 28•2 years ago
|
||
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.
Severity: major → --
You need to log in
before you can comment on or make changes to this bug.
Description
•