Closed Bug 51826 Opened 25 years ago Closed 23 years ago

implement advanced options for save-as dialog

Categories

(Core Graveyard :: File Handling, enhancement, P3)

Product:
Core Graveyard
Component:
File Handling
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED INVALID

People

(Reporter: dr, Assigned: mpt)

References

Details

(Keywords: helpwanted)

It would be nice to download an HTML document without having to download all the associated images and other objects, and without all the relative links being broken. It would be trivial to insert a <base> tag in the HTML header indicating its "intended" location (i.e., if you downloaded foo.html from http://bar.com/baz/, insert <base href="http://bar.com/baz/">). It would also be pretty simple to write UI for this: an extra "save-as" menu item which appears when the content type is text/html, or a checkbox in the save-as widget, or something...
Status: NEW → ASSIGNED
Target Milestone: --- → Future
This could be networking. But a cool idea (epesially for testcases)
Very cool idea. This would basically be a lightweight bug 40873 or bug 11632, and it's exactly what's needed when making testcases. If we go with checkboxes within the save-as dialog, I'd like to also see a checkbox to add "saved from [url] at [time]".
with respect to ui design, it would probably be best to have this sort of thing in the save-as dialog (to prevent menu clutter), perhaps in an "advanced options" tab. i'm sure there's more blue-skying going on in this area... it would be relatively easy to implement ui for this, but i'm guessing it would be slightly more difficult and counter-political to migrate windows (and mac?) from their native dialogs to our "xp" one. it would also be somewhat tricky to make the xp filepicker truly cross-platform (filters and stuff are all different). un-futuring, setting component to "gui features," and cc'ing ben and bryner for help/advice.
Component: Browser-General → XP Apps: GUI Features
Keywords: helpwanted
Summary: implement save-as with option to insert html:base → implement advanced options for save-as dialog
Target Milestone: Future → ---
from 11632, more blue-sky: ------- Additional Comments From Matthew Tuck 2000-10-02 10:18 ------- Assumedly this should also handle frames. Or should the only option be "Save Frame With ..." Whatever we do here, I think it's best if we have just one save action, and pop up a dialog with all the options if the file is HTML. I'd say a user could expect a normal HTML save to work either way, and often might want it to work different ways at different times. I believe there is a facility with most, if not all, file pickers, to add extensions to the dialog. Perhaps the options would be best off there.
snooping some more... there should likely be an option for save as mhtml (see bug 40873) in this dialog. i'm closing 11632 as a dup (yes, i know it came first, but whatever...) and cc'ing the interested parties there.
*** Bug 11632 has been marked as a duplicate of this bug. ***
forgot to cc matthew tuck...
QA Contact: doronr → sairuh
Looks like we're going to want to use a big drop-down box, with all the possibilities for HTML save. =)
only if they're mutually exclusive, which they may not be... i don't want to rule anything out -- let's get all the ideas together first and then figure out sensible ui for it.
I don't think bug 11632 is a duplicate. This bug is about adjusting URLs for page objects when saving a remote HTML file, so that they still point to the correct resource. Bug 11632, on the other hand, is about saving the page objects together with the remote HTML file.
mpt: this bug has been changed to encompass all the features proposed in 11632, of which there were several, and others. regardless, the key difference is that this bug will get worked on. also note that i've cited 40873 as a reference, since providing ui for saving as mhtml would be in this bug's scope, but supporting mhtml would be in the domain of those who felt comfortable hacking the content sinks, etc.
*** Bug 25756 has been marked as a duplicate of this bug. ***
I think a very important issue for *ML-pages is including external style sheets, javascripts and so on.
Dan, the way to get a bug worked on is to reassign it to someone who will work on it, not to open a new bug asking for exactly the same thing. And a bug should not be `changed to encompass all the features proposed in 11632, of which there were several, and others', because those features will get implemented, verified, regressed, etc at different times. One Issue Per Bug Report, please. Saving as MHTML should only be an option, distinct from saving objects in the same folder, as most HTML-processing tools do not support MHTML (such as, oh, Mozilla Composer, for instance), whereas they'll work fine with a file pointing to objects in the same directory. So what advanced options for saving are we looking for here: * Save with Encoding (so as to get rid of that godawful `Save as Charset' menu item): popup menu * Save format -- HTML, prettily-indented HTML (those two removing the need for the Composer pref), compressed HTML (removing unnecessary whitespace), RTF, plain text (.txt), plain text with layout (.asc): popup menu (native dialogs have such a popup menu already, so that's not a problem by itself) * Retain links to remote documents: checkbox (on by default) * Include objects: point to remote locations (default) [bug 51826], don't do anything, save as MHTML [bug 40873], save in same folder [bug 11632], save as Zip/StuffIt archive: popup menu * save frames: save just current frame (default), point to remote frames, save in same folder, save as MHTML: popup menu. What this is going to require on the UI level, I think, is for the code which opens the filepicker to accept a chrome URL to an XUL overlay (containing the UI controls for these options) as one of its arguments. On X this can just be inserted into the XUL filepicker itself: on Windows and Mac it will require an extra dialog containing the overlay (and Ok and Cancel buttons) to come up before/after the save dialog, until someone is brave enough to write code that converts the XUL into native controls for the native dialogs.
Also .jar ;-)
mpt: spank me, baby, i've been sooo bad. this bug is here to gather ideas for advanced save-as options (and you'll note that there are significantly more ideas gathered here now than there were in the bugs i closed), and to implement a coherent ui for them. notice that the component is "gui features" and not "implement everything"? good boy. also, i disagree with your implementation approach very much. i'd have a difficult time taking anybody who claims to be a ui person seriously, who thinks it's okay -- even as an interim solution -- to popup an advanced save dialog before even letting the user at the basic options they're significantly more likely to use on a regular basis. now pay attention, big guy, and i'll say it again: i'd like to get all the ideas together first, and then figure out sensible ui and implementation.
I think that when mpt said "popup", he meant "dropdown listbox".
nope; he was, to his own discredit, crystal clear: "on Windows and Mac it will require an extra dialog containing the overlay (and Ok and Cancel buttons) to come up before/after the save dialog"
If there's going to be any spanking in this bug, please un-cc me first.
All right, that's enough. Jesse and Dan, you're talking at cross purposes -- drop-down listboxes are the (unfortunate) Windows implementation of popup menus, but that's orthogonal to the issue of the dialog (containing those popup menus) that would `come up *before*/*after* the save dialog'. Dan chose to infer the more awkward of those two choices, i.e. before the filepicker, but never mind. And yes, I have been known to propose godawful interim UIs as a kind of itching powder, so that someone will scratch the itch and put in the effort to implement the more usable long-term solution more quickly. So sue me. My point was that eventually it should look something like this: | | | |:| | | | | |V| | | +-------------------------------+---------------------+-+ | | _Name: [KingFred ] ( N_ew Folder ... ) | | F_ormat: [HTML compressed :^] | | | | En_coding: [Western (ISO-8859-1) :^] | | Save _frames: [....... :.... :.] | | Object_s: [link to remote objects :^] | | [/] Update _links to point to remote documents | | [ ] Save as _template (read-only) | | | | ( Cancel ) (( Save )) / +----------------------------------------------------------/+ But until people did the platform-specific hackery of the native filepickers to get that to work, it *could* work like this instead: | | | |:| | | | | |V| | | +-------------------------------+---------------------+-+ | | _Name: [KingFred ] ( N_ew Folder ... ) | | F_ormat: [HTML with options ... :^] | | | | ( Cancel ) (( Save )) / +----------------------------------------------------------/+ | | \|/ V +------------------------------------------------+ | Save as HTML with Options :::::::::::::::::::::| +------------------------------------------------+ | HTML f_ormat: [compressed :^] | | | | En_coding: [Western (ISO-8859-1) :^] | | Save _frames: [....... :.... :.] | | Object_s: [link to remote objects :^] | | [/] Update _links to point to remote documents | | [ ] Save as _template (read-only) | | | | ( Cancel ) (( Save )) | +------------------------------------------------+ That way, we don't have access to features held up by the problem that someone hasn't done the perfect UI for them yet. (And if this bug is indeed just for the GUI for the various features, well that's even more reason not to mark the other bugs -- RFEs for the features themselves -- as dups.)
removing blake due to spankage. matthew: you almost make it sound like you /intended/ to propose the "godawful ui." almost. and if you'd been paying attention instead of spouting ui out of your ass, you would have heard me say twice that we'll come up with a ui that makes sense based on the features we'd like, not the other way around. your statement that i chose to infer the more awkward of two choices is insulting and catty, since you were the one who posed both awkward choices in the first place. this is as though i had said, "would you like me to kick you in the balls or in the head," and laughed at you for choosing either. you want to reopen 11632? fine. see if it gets worked on. you want to force me to fix problems the most ass-backwards way imaginable because it'll make you feel as though you've contributed? fine. the bug is all yours, baby.
Assignee: dr → mpt
Status: ASSIGNED → NEW
spam: over to File Handling. i have not changed the assigned developer [or the other fields for that matter], so if anyone realizes that a bug should have a more appropriate owner, go ahead and change it. :)
Component: XP Apps: GUI Features → File Handling
adding self to cc list
Marking invalid due to spankage and overgenerality. Please file only one RFE per bug report. Thankyou.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
mass-verification of Invalid bugs. if you don't think the report is invalid, please check to see if it has already been reported (it might be a duplicate instead). otherwise, make sure that there are steps (a valid test case) that clearly display the issue as an unexpected defect. mail filter string for bugspam: SequoiadendronGiganteum
Status: RESOLVED → VERIFIED
I do not know why this has been marked invalid. I do not think the resolution has been justified in the comments. I found this bug because I was going to file a simlar bug myself. If this bug is too vague can we reopen it as a meta- bug and file seperates on the indivdual options people would like. I personally think the save-as could be kept as it is now, but that that the dialog could be increased in size with an "advanced options" button (which I seem to remember Macromedia do in their web design software). This advanced options button would be, by default, set to default to current behaviour (although users could use about:config to change the default options). The following is my suggestion for some advanced options. I am willing to file these bugs seperately if this is thought to be more appropriate, although a meta-bug would be useful. The advanced options could include some or all of the following -- obviously the following is not a suggestion of how it would actually look -- that can be considered when a consensus is reached as to which options to include: ---------------------- ADVANCED SAVE OPTIONS: ---------------------- checkbox: include URI reference of source page as comment [I suggest a default of yes for this option as opposed to the current Mozilla behaviour -- this is one of the few things MSIE gets right] checkbox: change all relative hyperlinks to absolute hyperlinks checkbox: change all relative URI references in metadata to absolute URI references checkbox: (if document contains no base element) alter the base of the saved page to the URI of the source page ----------------------------- ADVANCED LINKED FILE OPTIONS: ----------------------------- drop-down: save linked files: in the same directory as the the HTML document in a *_files sub-directory checkbox: save all linked objects (inc. images) (and relativise links to) checkbox: save all linked stylesheets (and relativise links to) checkbox: save all client-side scripts (and rleativise links to) checkbox: save all linked frames (and relativise links to) checkbox: save all linked favicons (and relativise links to) checkbox[that checks all other advanced-linked-file-options chekboxes when checked]: save all linked files (and relativise all links to)
I think this bug is prefectly valid. Could it be re-opened?
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.