Closed Bug 11632 Opened 26 years ago Closed 24 years ago

[RFE] Save Page With Images, Stylesheets, Objects, Applets

Categories

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

Product:
Core Graveyard
Component:
File Handling
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.7

People

(Reporter: CodeMachine, Assigned: bugs)

References

Details

(Keywords: helpwanted)

Attachments

(2 files, 7 obsolete files)

widget/ changes [work-in-progress patch]
2.25 KB, patch
Details | Diff | Splinter Review
another XPFE patch
35.86 KB, patch
hewitt
: review+
Details | Diff | Splinter Review
There's quite a few people who request saving pages with images. I guess this might include any objects, and applets too. I haven't noticed this in apprunner, if it's there please feel free to shoot me.
Summary: Save Page With Images → [RFE] Save Page With Images
Target Milestone: M14
This would be a great feature. If there isn't enough time to implement this, I wouldn't mind if when you save the webpage to disk (the HTML), all relative image and object URLs (i.e. /images/duck.gif) are updated so that when I browse the page locally, it can still render images. (The images, applets, etc. would still have to be loaded from the internet). I'm not sure if this defeats the whole purpose of the feature?
Yes that would be nifty too. Save With Images (Translate Relative URLs to current absolute value) and Save With Images (Save Images, Translate URLs to save directory)
Status: NEW → ASSIGNED
This is our 'software management' group project for Software Engineering Course. Or at least we'd like it to be :)
QA Contact: beppe → paulmac
Assignee: don → cs470y
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
QA Contact: paulmac → sairuh
spam: reassigned QA contact to self.
cs470y@capybara.org, has any progress been made on this? For that matter, given "Or at least we'd like it to be :)", has a start been made? The same issue has been raised in bug 23207, "Save as... extended features suggestions (images, stylesheets, etc, with page)", currently M20. If there is no response, this bug should probably become a DUP of bug 23207.
How come this is still M14? M14 is already out!
M20
Target Milestone: M14 → M20
*** Bug 23207 has been marked as a duplicate of this bug. ***
Passing from cs470y@capybara.org to sfraser@netscape.com based on no response; CS470, if you are still out there, speak up now... Setting the 4xp keyword; IE has this feature. -------------------- What IE does saving as "Web page, complete": IE 5 does 3 things: 1. All relative URLs are converted to absolute form; no <BASE> element is added. 2. A folder is created under the folder where the .html file is being saved, named after the file being saved (for the example below, "Sites index_files") 3. The DOCTYPE and <HEAD> are "adjusted" to let IE find and use that folder. To use a concrete example, IE adjusts the top of the file at http://www.albedo.net/sites/ from <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML><HEAD><TITLE>Sites index</TITLE></HEAD> to <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <!-- saved from url=(0032)http://www.albedo.net/sites.html --> <HTML><HEAD><TITLE>Sites index</TITLE> <META content="text/html; charset=windows-1252" http-equiv=Content-Type> <META content="MSHTML 5.00.2014.210" name=GENERATOR></HEAD> Notably, IE5 saves stylesheets as well as images in that folder. ---------------- What Mozilla could do: There are three levels to what Mozilla could do: 1. Change relative URLs to absolute and stop there. 2. Emulate IE, perhaps with a nicer implementation. 3. Save everything in one file as MHTML (multipart/related, rfc2557). (1) is barely an option; so long as the files loaded with the .html file remain in the cache, it would work, but it would be a lie to call that "saving with". (2) Implement what IE does. Rather than cluttering up anywhere and everywhere on the user's disk with files for saved webpages, though, it might make sense to store them in a folder called Offline under the user's profile; it would then be necessary to make only one adjustment to the saved file: add a line like: <!-- Base: C:\Program Files\Mozilla\Users\user1\Offline\filename_html_files --> which would allow the .html file to be saved anywhere or even moved and still work on the local machine. Note that (2) also implies always checking, at least for .html files retrieved from a file:/// URL, to see if the related files are stored offline. The attendent problems of comparing against possibly newer versions in the cache and/or at the original location are left as an exercise for the reader :-} (3) Save as MHTML. The MHTML spec, rfc2557, provides a way to store all files associated with an HTML file in one file, as multipart/related sections. See http://www.faqs.org/rfcs/rfc2557.html Of course, for this to be useful, bug 18764, "RFE: Full rfc2557 MHTML multipart/related support in BROWSER", would also need to be done, so that the saved file could be viewed again. In practice, (3) could not replace (2); it would be another option. RFE bug 40873, "RFE: Save as rfc 2557 MHTML; complete webpage in one file" filed for (3).
Assignee: cs470y → sfraser
Status: ASSIGNED → NEW
Keywords: 4xp
Summary: [RFE] Save Page With Images → [RFE] Save Page With Images, Stylesheets, Objects, Applets
*** Bug 41189 has been marked as a duplicate of this bug. ***
"Rather than cluttering up anywhere and everywhere on the user's disk with files for saved webpages, though, it might make sense to store them in a folder called Offline under the user's profile" I'd disagree. The related files have no purpose in life other than to be displayed with the original page. To keep them in a separate directory apart from the original file is asking for clutter. Plus, there's a user's view aspect to it. If I save a page, I want it all saved in one place. Now, MHTML is ideal (my primary choice) but if not, I don't want the images saved off in some place where I have to keep track of its relationship with the primary page. If I delete the page, I want the images right there to delete. If we centralize the image save location, I'll have some directory filled with billions of image directories. Where are all the original files? Do they all still exist? Going for such a thing is, IMHO, asking for a file maintenance nightmare. My hard drive is disorganized enough--I don't need Mozilla's help. Microsoft (for once, at least) is doing it right.
moving to future milestone
Assignee: sfraser → beppe
Target Milestone: M20 → Future
This is a disappointing regression relative to 4.x behavior, where we always save images along with the HTML page when we do a "Save As" with a remote document. But to do that, as discussed above, we have to do the "right thing" with the img src URLs, etc, and this is all part of the Publishing management that we unfortunately had to give up for our first release. So it is probably one of our most notable omissions, but it seems to late to try to tackle this now. I agree with the decision to not do this.
moving back to previous owner
Assignee: beppe → sfraser
*** Bug 43641 has been marked as a duplicate of this bug. ***
don't let this bug unnoticed!! look at my comment in bug http://bugzilla.mozilla.org/show_bug.cgi?id=25756. Many users, include me, will be uncontent with it!
adding help wnated keyword
Keywords: helpwanted
*** Bug 47598 has been marked as a duplicate of this bug. ***
*** Bug 47598 has been marked as a duplicate of this bug. ***
*** Bug 49042 has been marked as a duplicate of this bug. ***
See also bug 40253: Execute the download of all links
This is a dup of 36419 or 51826, take your pick. Or, vice-versa.
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.
resolving as a dup of 51826, which i hope to be working on sometime in the near future. those cc'ed on this bug are cc'ed on 51826 now. *** This bug has been marked as a duplicate of 51826 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
Reopening. Bug 51826 was a meta bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
*** Bug 60004 has been marked as a duplicate of this bug. ***
How many dups does it need for the mostfreq keyword? I'm adding it. If you disagree, feel free to remove it again.
Keywords: mostfreq
Doesn't this work in a rudimentary manner if you open the page in composer, and save the page from there? Someone could do a quick fix by hooking up these steps to a single command. Not perfect, but better than nothing.
Look at: http://bugzilla.mozilla.org/show_bug.cgi?id=64286 Saving all the stuff in a browseable .zip archive is another solution, for me it would be the simplest one, no need to change links, simple to transport, would respect the given tree-structure...
mathew, as the reporter, could you please add "mozilla0.8" to the "keywords"?
Hmm, I don't think only the reporter can nominate. Personally, I think moz0.8 is a little early for this considering what else is needed, but you seem to want it, so I'll add it.
Keywords: mozilla0.8
Removing '4xp' keyword since Navigator 4.x doesn't have this feature. (The definition has changed somewhat since Sean added the keyword; see http://bugzilla.mozilla.org/describekeywords.cgi)
Keywords: 4xp
*** Bug 69464 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.8.1
Keywords: mozilla0.8
0.8.1 is nearly here and already branched, I don't expect to see this done by 0.9 so I'll nominate for mozilla 1.0
Keywords: mozilla1.0
This so isn't me.
Assignee: sfraser → pchen
Status: REOPENED → NEW
IE has this feature, the Mozilla based K-Meleon has this feature, even winEmbed.exe and mfcEmbed.exe which are included in the mozilla win32 and embed zipfiles. So at the moment our embedding demo programs have this feature but mozilla doesn't. Research shows that 9 out of 10 cats prefer it :)
Keywords: nsCatFood
*** Bug 76018 has been marked as a duplicate of this bug. ***
removing mozilla0.8.1 keyword.
Keywords: mozilla0.8.1
Keywords: mozilla0.9.2
*** Bug 77013 has been marked as a duplicate of this bug. ***
nav triage: not a feature we're doing for this Netscape release.
Keywords: nsCatFood → nsCatFood-
Making Mozilla/Netscape 6.x probably the only browser on windows that doesn't support this. Even the embedding demo apps that come with mozilla seem to support this.
renominating for catfood, per david's comment.
Keywords: nsCatFood- → nsCatFood
From http://slashdot.org/comments.pl?sid=01/05/08/0046256&cid=429 : * The ability to save web pages intact. IE has this. Opera has this. Konq will hopefully get it soon.
Keywords: nsbeta1
Keywords: nsbeta1, nsCatFood → nsbeta1-, nsCatFood-
i'd like to save html and images to a SINGLE file, like internet explorer 5 in windows 2000 (.MHT files). this file format is multi html, i think, and it's also used in outlook express to send/receive email in html format. so, if the mozilla mailer already supports this file format, it shouldn't be too difficult to make the browser save these files. you find the ietf RFC at: http://www.dsv.su.se/~jpalme/ietf/mhtml.html i have saved lots of pages in mht format, so i can't switch to mozilla until mht files are supported (both reading and writing) thanks.
> i'd like to save html and images to a SINGLE file, like internet explorer 5 in > windows 2000 (.MHT files). That specific issue is covered by bug 18764 (reading MHTML) and bug 40873 (writing MHTML).
Depends on: 82118
I created a tracking (meta) bug 82118 to track these kinds of bugs and to unify the efforts. Maybe a few duplicates will also become aparent this way - then we can assign the keyword MostFreq.
Removing dependancy to bug 82118 as it should be the other way round (bug 82118 depends on this bug).
No longer depends on: 82118
Blocks: 82118
Embedding has a persistence object capable of saving documents and all their images, stylesheets etc. to file in the way desired. Mozilla uses a quite different object called the stream transfer object. This is why embedding samples have the ability to save a document and all files but Mozilla doesn't. Bug 77909 describes some of the cleanup work going into the web browser persist object at the moment. Once that's done it should be possible to consider moving Mozilla over to using it.
Depends on: 77909
*** Bug 86456 has been marked as a duplicate of this bug. ***
Keywords: mozilla0.9.3
Assuming this goes ahead, if URLs are amended when saving webpages, please don't alter/break internal relative addressed links like IE5, which turns this: <a href="#TOP">Back to top</a> into this: <a href="www.foo.com/webpage.html#TOP>Back to top</a> Which is pretty useless when the webpage is now C:\My Documents\webpage.html
gav: I'm working on bug 40873, which is one possibility to implement this RFE. URLs *must* be altered to make this work with frames, but they can still be relative. However, it is not trivial to resolve links in MHTML documents (I've done this with a new protocol handler; NS 4.x and current Mozilla builds rewrite the links when displaying, but fail for some (NS 4.x) or most (Mozilla) documents). I haven't looked at IE yet because it needs Outlook for MHTML and I have not installed it, but if you mail me an MHTML document produced by IE I'll see if it will work with Mozilla once bug 18764 is fixed (much of it is already working in my tree).
*** Bug 92309 has been marked as a duplicate of this bug. ***
*** Bug 92421 has been marked as a duplicate of this bug. ***
Nominating nsenterprise, this is a feature used by many people in IE and is one of the major feature parity issues between the browsers. If a corporation needs this feature in their browsers they'll not deploy Mozilla/Netscape
Keywords: nsenterprise
Blocks: advocacybugs
No longer blocks: advocacybugs
Blocks: advocacybugs
As a user of Netscape and IE, I have felt the feature of Save As is something sorely missing in netscape. As someone mentioned, even Opera has the feature (though buggy) and IE is very good with saving the entire web page or creating a Web Archive... Mozilla can use the Page Info to determine the image names and copy the images from the cache onto some persistent store on the hard disk. If page Info is correctly implemented, the only thing that needs to be changed is the source to point to the images in the local store rather than on the remote server.
*** Bug 95571 has been marked as a duplicate of this bug. ***
Removing nsenterprise nomination, adding nsBranch.
Keywords: nsenterprise → nsBranch
Galeon now has this functionality (http://galeon.sourceforge.net/news.html). I don't know anything about the code used by the galeon folks to do this but maybe it can be ported to mozilla?
Keywords: nsBranch → nsbranch
See comments from Adam Lock 2001-06-03 10:27 I asked this question a while back because all the Win32 embedding demos supported this. But atm it's only impossible in embedded mozilla and not mozilla itself
1.183 mpeseng Aug 3 15:56 2001-08-02 Marco Pesenti Gritti <marco@it.gnome.org> * src/embed.c: implement save with content Anyone want to politely ask Marco about contributing the same code to mozilla under MPL?
Galeon is just using nsIWebBrowserPersist. See bug 77909
*** Bug 98864 has been marked as a duplicate of this bug. ***
Blocks: 99227
removing some obsolete keywords, nsbranch-, ->ben/0.9.6 since he owns a similar plan item.
Assignee: pchen → ben
Keywords: mozilla0.9.2, mozilla0.9.3, nsbranch → nsbranch-
Target Milestone: Future → mozilla0.9.6
No longer blocks: 99227
Bearing in mind that an external stylesheet can '@import' yet another stylesheet, it would be good if the latter could also be saved.
BTW I think, that correct implementation of this bug is also depending on bug 40867 (Need means to reuse/reload current page without refetching from server). Can somebody confirm my opinion?
Depends on: 102556
Shift, accept, reprioritize
Status: NEW → ASSIGNED
Priority: P3 → P2
Target Milestone: mozilla0.9.6 → mozilla0.9.7
We also shouldn't forget any background images specified in internal, external (including @import in internal or external) stylesheets.
All the code for saving pages and linked images, js, css etc. is now in Mozilla. It just requires someone to brutally kill the stream xfer object and start using the web browser persist object instead. See bug 102556. As regards fixing up and saving CSS; this will only be feasible if we have some easy way of walking through a set of rules specified in each CSS file and inline within the HTML, for fixing it up and dumping it out again. Does anyone familiar with the code know if this is possible?
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 → File Handling
I'm sure it's possible to enumerate the stylesheets for the current document. inspector does it, hyatt knows how too. Thanks for the pointer, Adam. The web browser persist stuff looks spiffy.
Target Milestone: mozilla0.9.7 → mozilla0.9.6
OK. What follows is a work in progress code dump. Nothing is final yet, however: - Save Page With Images/Objects/Etc works (via filter selection) - Save Page as HTML only (filter selection) - Save Page as Text only (filter selection). I need to: - make the filters (and thus save options) differ depending on the type of document loaded (web page, image document, frameset, other) - make this work on unix (easy modification to the XPFilePicker) - poke a mac person into making this work on Mac (modification required to Mac file picker). For my own personal reference, save option availability matrix: With Objects HTML Only Text Only All Files Web Page Yes Yes Yes No Image Doc No Format Only No Yes Frameset Yes Yes No No Other No No Yes (*) Yes (* - if text document)
Blocks: 99642
Blocks: 107067
Keywords: nsbranch-
*** Bug 107079 has been marked as a duplicate of this bug. ***
Would it make sense to add "MHTML" to the summary to make this bug easier to find?
+ if (uri.scheme == "http" || uri.scheme == "ftp" || uri.scheme == "about") + mimeTypeString = "text/html"; // Assume text/html for web documents ben: can we hide this behide netwerk or mime? plairo: not if the file format doesn't match mhtml which from my current reading it does not.
I'm just jumping in here, I haven't read all the bug comments but I'd like to note that on this feature: IE probably parses the html as it is writing to disk of URL tags like: <IMG src> to strip the url='url' for the filename and then add the saved local directory back to before the '/' + filename. Then continues writing and parses the next one it comes to. It doesn't seem to change <a href> tags. So when the user views a saved page it will load all images up into the page. Objects and applets do not appear to be saved in IE, so this would probably be a feature+some over IE's method. -dennis
ok, read the comments now: forgive me if your patches and inclination already have this working please. Just tossing out some insight :) I also use IE for this, and severely miss this feature in netscape, adding objects and stylesheets, etc. would be great! Anyway IE grabs the html file from the website again (within its dialog) after you select a directory.. so it would then parse on writing to disk. My first inclination to how this parses a given URL .. is it grabs the "directory + '/' + filename" URL string.. starts from Right works its way Left and searches for the first '/' then truncates the leftovers on the left, or (figures strlen - 'position x of "/" and stores x+1 + (strlen - x) chars starting from the right) then concatinates the saved directory name to this stored string as the URL so we have 'saved directory string + '/' + stored string) and writes it disk. -dennis
for most recent patch, I am puzzled in this area: + if (extensionIndex <= lastSlashIndex) { + if (uri.scheme == "http" || uri.scheme == "ftp" || uri.scheme == "about") + mimeTypeString = "text/html"; // Assume text/html for web documents + } 1) what about https? what about file? any others? (javascript:?) 2) I don't see where mimeTypeString gets set for images (aContextElement && aContextElement.localName == "IMG"); does that matter? Can the determination of a default file name be factored into a separate function? (GetSuggestedFileName?) I think it makes more sense to use an existing filename instead of a title (if it's available); so the order would be: 1) Use the caller-provided name, if any 2) Use the file name, if there is one in the URI 3) Use the document title, if there's a document 4) Use the host When trying to get the fileName, seems like the best thing would be to call nsIURL's GetFileBaseName implementation. Then you wouldn't need to do indexing, substrings, etc. more later...
We can't just save applets' jar files to disk because of the restrictions that the Java platform's sandbox places on applets. For example (IIRC), unsigned applets may not accept incoming network connections, they may not access any host save the one they were served from, nor may they access the local filesystem. (By the way: It's possible for signed applets to circumvent these restrictions, but signing applets requires a developer certificate that currently costs hundreds of U.S. dollars per year and is now available only to businesses.) Would it be possible to "wrap" Java applets with some kind of data storing a list of what hosts they are allowed to connect to?
'background' image attributes need to be addressed too then.. -dennis
mfcEmbed already contains the code that saves webpages and their contents. Run that if you want to see what is and isn't saved. Generally speaking it will save: 1. The web page, fixed up 2. Linked files such as (background) images, stylesheets and js 3. Frames and IFrames Fixing up consists of removing the BASE element if present and making all URI attributes absolute except in the case of linked files which are fixed up to point to their local copies. Most of the common elements are fixed up but there could be some omissions. Currently there is no fixup at all of stylesheets or javascript. Potentially stylesheet info could be fixed up but I haven't looked into it. Javascript will never be fixed up because you'd never be able to do it properly.
brade: yeah that's why i asked about hiding. other protocols include data: :-)
*** Bug 108329 has been marked as a duplicate of this bug. ***
Kathy - 1) the case where explicit scheme checking is done is a case that a fair chunk of documents will not fall into because getMimeTypeForURI will succeed (i.e. documents that have extensions). There's no special case for images here because if you have an image without an extension, there's really nothing I can do to offer meaningful filter options.. other than "All Files" (which is what you get currently). I *do* try to do a bit more checking for html docs though because docs like toplevel domains, like "http://www.cnn.com/" need to show the HTML filter set. This code provides that. Good catch with https however. file:// URLs typically have extensions, from which the MIME type can be determined. Otherwise, they'll just show the "All Files" filter. That said, I do rather dislike having this hard-coded list here. It might be possible to fetch the start of the file to get its content type. I can add a note to that effect in the code. I was blindly following IE's lead with using the title as the first choice for file name, but I think that remote filename is better, so i've changed that. These changes are in the updated patch I've just attached. Also in this latest patch is what I believe to be an implementation of 'filterIndex' in the XP file picker. Looking for someone to verify this patch on linux.
*** Bug 109413 has been marked as a duplicate of this bug. ***
Two points. Firstly, I find it astonishing that getMimeTypeForURI doesn't work for URIs without extensions -- isn't that what the Content-Type: header is for? That's surely a bug which should be fixed there rather than hacked around with here. Secondly, please don't use `All Files (*.*)' in the XPFE filepicker (or in the Windows filepicker, if you can avoid it). Saving a file as `all files' has never made any sense on Windows (does it mean it overwrites all of my other files, or what?), and it doesn't make sense on any other OS either. `Original File' would be much more understandable.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment on attachment 56452 [details] [diff] [review] xpfe patch for save with objects I'd still like to see more factoring in contentAreaUtils.js. For example, I'd like to see the mimeService stuff in a separate utility function. Also, the filepicker could be a separate utility function. I'd also like to see the "getDefaultFileName" be a separate function. I'd like to see Composer use some or all of these functions instead of implementing them separately.
What is editor's planned use of this functionality? This is a browser feature. I thought you already supported this?
Composer 6.x doesn't support this functionality. However, it will when nsIWebBrowserPersist permits saving of text/plain (in addition to text/html) mimetype. That will come about via an api change (coming soon). I'd like to see Composer and Browser share as much of this JS as possible. (Composer's can be found in ComposerCommands.js at the moment.) Regarding your patch, if you specified the text/plain mimetype when saving, would that help you reduce callbacks and such or is there some other reason you need all that extra code?
I've modified this patch significantly. I hope to get a newer version posted by this evening.
Attached patch new XPFE patch (obsolete) — — Splinter Review
Latest patch to XPFE. Changes to content/ are no longer necessary.
Attachment #54336 - Attachment is obsolete: true
Attachment #54338 - Attachment is obsolete: true
Attachment #54339 - Attachment is obsolete: true
Attachment #54404 - Attachment is obsolete: true
Attachment #54405 - Attachment is obsolete: true
Attachment #56452 - Attachment is obsolete: true
One quick observation on the latest patch: getDefaultFileName might return a filename that has a character that would be bad for a filename (such as a colon). Also, if the user is trying to save "index.html" as a text file, you might be saving the file with the wrong extension (a better default filename might be "index.txt" in that example).
validate file names for Windows, Mac and Unix systems. If the user is saving to a text file, we should not change what they've typed in the field, and on Windows at least we've got no ability to change what's in the field when the filter selection changes (and I don't think we should go down that road as you'd not want to change text that a user had entered as opposed to default text, etc etc).
Attachment #59298 - Attachment is obsolete: true
*** Bug 113185 has been marked as a duplicate of this bug. ***
sr=hyatt
Comment on attachment 59462 [details] [diff] [review] another XPFE patch I am seeing </pre> at the end of two lines in nsFilePicker.js. Maybe that is mozilla screwing up, or maybe you accidentally inserted them in your files. weird. r=hewitt
Attachment #59462 - Flags: review+
for the record, r=brade
So.. did the patch that just went in end up using some sort of extension-sniffing for the type? Or is it looking at headers? Or what? I can't quite figure out the code... In any case, documents have a "contentType" property.... Ben, could your code just use that?
I sniff for content type now, not extension. the contentType field on document is irrelevant because it's for the case where we don't have a document that knowing content type is useful. Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → FIXED
'save page' menu items and context menus - and 'save image' do not work in 12-12 builds. No files get saved.. with any method.
Seeing the same problem as Dennis. Complete/HTML only/text do not save at all. Also, the file extentions are listed twice: Text File (*.txt) (*.txt) etc This should probably be backed out by tomarrows builds if there isn't a quick fix.
Nice feature, but how do I save a page with the orginal source code now other than copying and pasting the source code from view source? Sometimes, you don't want your links' and images' paths altered. e.g, you need to download a slideshow which has uses back and forward links in the page. Using this new save formatting options, none of the links on the page will work when you're offline since all the links are now absolute. A better implementation of this IE behavior would be to allow for "classic save as mode".
nevermind, I just figured how to save the page as html only. I never realized that option was available in the save dialog box.
I am using Traditional Chinese Windows 2000. If my folder full path contains chinese characters, the image cannot be displayed by IE because the path cannot be resolved .
icab does this well... http://www.icab.de/ (Mac only) create directory for content download content to desired depth, including/excluding desired media change URLs to relative gzip the whole thing When you open the gzip in iCab, it knows how to read the files in there. This also means that you can then do things with the gzip that you can't (readily) do with MSIE's web archive file format, such as gunzip it manipulate the downloaded data as you wish... or delete the stuff you don't want, and keep all the porn^H^H^H^H stuff you do want. -matt
it appears that possibly background images are not being saved. see bug 115532
can you zip (pkzip, not gzip) all the files to a single file ? I'm thinking to an option like "save with images as a single file"
If zipping, then tar/gzipping on unix-flavour builds and zipping on win builds (don't know about mac). All with a hidden pref to change the type of zipping.
compressing is a different bug ! Please don't SPAM this bug because it's fixed and it's working (see bug 40873) Thanks !
this feature has now been checked in.
Status: RESOLVED → VERIFIED
No longer depends on: 107521
Depends on: 107521
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: