It would be very convenient if when I was downloading something, and the download was stopped or interupted for some reason, that I could continue that download at a later date. Perhaps even if I pressed stop because I had to shut down Communicator and do another job, and when I started up to have it ask me if I wanted to continue where I left off.

I know this can be done in FTP (because NCFTP does it), and I believe it can also be done in HTTP (though I'm not sure how many servers support it). This would definitely be a neat feature. Perhaps it should be moved to Necko for consideration there, although it would also require some front-end work.

Setting QA Contact/Component

FTP RFE => Jud

Bulk move of all Necko (to be deleted component) bugs to new Networking component.

*** Bug 21254 has been marked as a duplicate of this bug. ***

adding Bill Law to the cc list as this involves UI/download dialog changes. I need to add the FTP protocol ability.

Moving post beta bugs to M18 which is now the post-beta milestone.

This is a dupe of bug 40265.

*** Bug 40265 has been marked as a duplicate of this bug. ***

*** Bug 34548 has been marked as a duplicate of this bug. ***

You might want to check bug 40265 for my comments. I suggested that when a download is cancelled, the user is given the option to either delete the partially downloaded file, or to leave it there. The latter option is the only one which makes sense if this enhancement is made.

I have been looking for this pretty obvious feature in browsers for years!! Let Mozilla be the one to finally get it! One should not need a program like wget or GetRight for this... Resuming is possible for both FTP and HTTP downloads if the server supports it, and most do, nowadays. Too often I get the overwrite dialog, and would love to see a Resume button in that dialog.

-> gagan

this could be in conjunction with an internal Mozilla Download Manager (like GetRight). A very important feature indeed. Would be nice if said DM were integrated into the mysidebar. Could someone please correct the target milestone to something that reflects the current milestone structure (mozilla0.8)? Thank You. BTW, this bug has been reported over one year ago.

Please also see bug 64887 for integration of this feature into a built-in "Download Manager".

Let's not make this "bug"'s workload too large at once or nobody will feel like implementing it. It's far behind target already - it needs a new, realistic target milestone! I consider just the "resume" button in an "overwrite" dialog very important, a full download manager is just further luxury (an optional next step), so let's not merge these two bug #'s. Keep 'em separated!

I just wanted to file a dupe. I cc myself, since I want to see this feature...

I believe dougt already has one for FTP resume.

4.x in Windows sorta supported resumes, sometimes it did work and other times it didn't. I think if you were downloading with 4.x in Windows and pressed cancel and then went back and downloaded again it would auto resume. (No, I'm not talking about the optional Netscape Smartdownload add on which was not part of communicator, the resume capability was in the browser itself) Anyway, it'd be a useful feature to have.

*** Bug 76886 has been marked as a duplicate of this bug. ***

Implementing this for HTTP would require: * adding Range: bytes=<current filesize>- line in HTTP request for download. For example: Range: bytes=123456- * having Mozilla accept and recognise HTTP response 206 or absense of such response. * displaying a dialog with Resume button if server supports resume. * appending the file with downloaded data if it is being resumed at correct offset. * initialise/update progress window accordingly. for FTP first two get replaced with: * sending a REST <current filesize> command. For example: REST 123456 * having Mozilla accept and recognise FTP response 350 or an error response. However here comes an issue of files on the server being replaced. For example files in Mozilla's nightly 'latest/' folder. You start downloading a file, then for whatever reason it stops. Meanwhile the file on the server gets replaced with new version. Then you resume it and end up with a useless file. Download managers like Getright remember and store original file size and it's Last Modified date/time until download is finished or removed from the list. We can't do that without creating an entire download manager for Mozilla. Unless download gets stored in Cache I guess. I am not sure where Mozilla saves a file during download. It doesn't appear in the destination folder until download finishes, nor in cache. Storing unfinished downloads in Cache will bloat it. I'm not sure if storing partial data in Cache (downloads or a web page) is a right idea at all. Although while browsing some sites, sometimes you wish Mozilla could resume page download as well. For example: http://www.wellnet-one.de/penguin.html

It may be doable to: - write size (timestamp?) info to the cache when a download starts - remove it if the download finishes successfully (this ensures information is saved even if mozilla crashes in the meantime) This info will only take a couple of bytes per download and mozilla could throw away data that is one week or older. This way only one week of crashed download information will be stored - hardly a load on the cache. How long it remembers could be made configurable in the future, but for now one week or so should do fine... OR simply leave it unsolved and add a warning to the RESUME dialog that if the file changed on the server in the meantime (does not happen all THAT often, especially in those 99% of all cases where you resume the file right after the download crashes) you will end up with a useless file. Really, resuming downloads will be a HUGE improvement even without being 100% air tight & fool proof. I'm not sure all third party download managers really check for this either. Marcel

shhhh. don't let the pointy heads hear about this.... :-) Lets see if I can get something to work for 0.9.1....

See http://bugzilla.mozilla.org/show_bug.cgi?id=78193 for explict pause/resume of downloads. It basically adds a couple of buttons to the download dialog. This is one step in the right direction. However, we still need persistance. Once we have that, the explict pause/resume will be nothing more than "eye candy". I am going to push this bug out a bit...

mass move, v2. qa to me.

Yes. Very important feature. I've heard that IE5.5 can do this (although I haven't tested it just yet), so there is a competition factor involved. Ideally, it should be possible to resume a file from all of these scenarios: * Connection with server is interrupted * Dialup connection is lost * Computer locks/freezes/loses power * The browser crashes (yes, it does happen...)

In order to properly resume a file without data corruption, besides the basic timestamp and file size checks it's also important to do a rollback: Instead of resuming at the exact point where the file stopped, do it from (eg) 4K back and then check that those re-downloaded Ks are the same in the local file. This way it can minimize data corruption in the original download -> why did the original download stopped?

The backend to this bug is already there (at least for FTP), as shown by the pause/resume buttons. Of the 4 cases Skewer states, we already handle two: * Connection with server is interrupted * Dialup connection is lost These can be handled just by clicking the pause button when the problem occurs. (I haven't tested this though.) * Computer locks/freezes/loses power * The browser crashes (yes, it does happen...) These need to be handled in a different way.

For the last two cases, can you not just check if the file exists already ? Then if so, offer the options of 'continue', 'overwrite' or 'cancel'.

This would involve some sort of logic with the temp dir and Netscape's alien-ese filenames. Right now, I think download links are saved as [gobbeldygook].ext in the system temp folder, but save link as is directly saved into the target folder, so that would need to change. Personally, I would have have both save as [actual filename][download date].ext. For example, if I downloaded netscape.zip today, it would be in the temp folder as netscape010604.zip. I think all of the platforms we're using support long filenames, right?

Then this needs to be dependant on bug 55690.

Ian, just out of curiosity, I was testing one of those cases that do supposedly work and this is what I've found: A. If I hit pause, and *then* disconnect from my dial-up I can resume as soon as I sign back on - works nice :-) B. If I am disconected (either by a lost connection or I manually close it) the download window status says "Download Complete", gives the percentage that was completed, the progress meter goes to full, and pause is disabled. No-can-resume :-( [Win2k, Build 2001060320]

RE: partially downloaded files -> the filename. How about doing it like getright: partially downloaded files are stored in the actual target directory and have the temporary filename"filename.MOZ" (or other extension). That way, when doubleclicking a *.moz file, mozilla could load and resume the download. :) Mozilla would maintain a database of partially downloaded files, and on restart would offer to continue the download. Once a file is fiished, the entry would be removed from the database (and maybe placed into a "recently downloaded" database list)

there is a reason that mozilla sticks to 8.3 filenames for any files it generates automatically but I can't think of it at the moment. It may be a platform thing (e.g. I don't think OS/2 supports long filenames if it is run on a FAT (Windows/DOS) filesystem). If this isn't an issue then I believe Peter's solution makes a lot of sense. Although it would have to be a setting that deletes the files after x number of days or if the partially downloaded files total x bytes. If there is a 8.3 filename limit for whatever reason, we could still use a variant of Peter's idea but just truncate the filename and change the extension to .moz, the full filename as well as other useful info (such as the full size of the file) could be stored at the head of the .moz files in a specified format. This data could also be used to check whether the contents of the file have changed (that's the main reason for storing the total size). of course once the download has finished this info would have to be stripped from the head of the file before it's renamed.

I think we should keep the user-selected filename in tact as much as possible (recognizability). I don't think the long filename will be an issue since an 8.3 OS will only allow 8.3 during the "save as" step (which is prior to the filename.moz step), or the OS will automatically trunkate whatever filename is entered in the "save as" dialogue. Either way, whatever filename is chosen will (hopefully) somehow be dealt with by the OS *before* mozilla stores the file with a changed extension. In the end, all mozilla is doing is changing the file *extension*. The "delete partially downloaded files after x days" is nice to have, but should include the option to "never delete partially downloaded files" (0 days?). The option to "delete partially downloaded files that are larger than x kb" is a little dangerous since partial downloads are most interesting (applicable) for large files, and keeping large partial downloads is likely to be desirable.

Is it actually neccessary to change the extension? Why can't filename.ext be saved as filename.ext.moz. This is the way Netscape SmartDownload does it (using .resume instead of .moz).

It sounds best to me to leave the file where it is and also not add a header or rename it. We want partially finished files to be useable. For instance a 50% finished JPG or MP3 is viewable/playable. But not if you add a header, change its extension or move it to where the user can't find it. Also who says there's enough space on the temp/cache drive for those HUGE downloads? User might not pick a certain target directory for nothing. I would say keep the info about unfinished files in a separate file in the cache directory. Store paths and if you need to positively identify the half finished files, use a checksum or the last 4K or something. Flush info from database after 1) the unfinished file has been deleted by the user and 2) after a user configurable timeout has expired. Where #2 might benefit from a "retry/keep/delete" dialog. Also it might be good to do this in steps. A full fledged download manager might be too much work to finish sooner than mozilla3.5, but a "resume" button (without checks) in those all to familiar "overwrite y/n" dialogs might be easy enough for the next milestone, and already a large improvement. We've talked about this for LOTS of milestones now, but doing it in steps might help it actually happen, too. JMHO.

Better then to add a pref to add/not add *.moz to the filename for user-selected files (mp3, jpg, etc.). Few people will want to look at a half finished jpg or listen to 12 secs of an mg3. However most people will need to know that an *.exe, *.zip, *.wpd or whatever is actually a *usable* file (it is highly confusing to doubleclick a file and receive an error message - AND not have the download resume). Anyone wanting to view/listen to an unfinished file can simply delete the .moz ending. Additionally, the *.moz ending will allow to easily resume forgotten unfinished downloads. All this usability (by removing the .moz) and resumability (by doubleclicking) is only useful if the partially downloaded files are where the user selected them to be (not in some temp folder most don't even know exist let alone where to find it).

Here's what I would do: Don't put anything into the target folder until the download finishes. Downloads are placed in some user folder (not cache, maybe a download folder in the user dir). Two files are stored, the half-saved, let's call it a PNG file, and the .MOZ file containing the filename of the PNG file and whatever else. When Netscape is first opened, the user sees a message "Download of the following files was interrupted: [Listbox containing filenames of interrupted downloads that are in the DL folder] [Save Progress As...] Would you like to resume these downloads? [Resume All] [Resume Some] [Resume None] Resume All tries to resume all the downloads, resume some lets the user pick which downloads to resume, the rest being left in the download folder, resume none leaves everything in the download folder (these should "expire" at some point), and Save As lets the user save the selected file in the listbox, half-downloaded, wherever they want it.

and here's the arguement [again] for using .resume (.moz .idontcarehowlongourresumeextensionisnowjustdeal): if we want to color the file w/ an icon indicating both its file type and its progress we can't use its native extension w/o seriously harming os performance. whereas, if we use .resume or .moz it's trivial to paint the icon and give a tooltip explaining where the file came from, how much we have and what file type it will be. and here's the argument for 8.3: we need it because some things need it so don't try to ignore it, just live w/ it. this isn't a big deal. On win32 the file will be foobarbaz.bip.moz which might be foobar~1.moz or foob4sa3.moz (nt has a very different name mangling algorithm) or even foobarba.moz (9x can be forced to be nicer...) if we ever need to do 8.3 then something does that for us and since we have to store the url and filename and stuff elsewhere we also store the final file name (big deal). skewer: i'd prefer a resume downloads siebar or just another entry in the download manager (sidebar/window). some download managers maintain the list of downloaded files across sessions. *shrug*. however if you want anything resembling a download manager i suggest you write as much of the code yourself and attach it to bugzilla. someone will be much more willing to help if you take steps to provide code.

I think it might be a good idea if this bug were merged with bug 55690. It seems like they are both talking about the same thing now.

I disagree, the core issues are completely different.

Aaron, it depends on how 55690 is implemented. What I suggested in there was this: 1) User clicks to download file. 2) File begins downloading to /tmp as usual. 3) User now inputs filename for saving to. 4) *Mozilla checks to see whether the file name given already exists.* - If it does exist, and the existing file is *larger* than the downloaded chunk, the user is asked if they want to continue downloading, or to overwrite the file. If they select to continue loading, we delete the temporary chunk, and continue with the existing file. - If the file does not exist, or is *smaller* than our new chunk, or the user has chosen to overwrite, copy the downloaded chunk to the selected location, and continue downloading from there. If the other bug were fixed in this way, it would kill 2 birds with one stone. That's all I'm going to say. If anybody agrees with my idea, head over to bug 55690 and give me some support.

But that would involve adding another confirmation, something that should be avoided whenever reasonable. Isn't this a decision the browser can make for itself?

Another confirmation ? Why ? All the user will see is: a prompt to choose a file location, and then another prompt asking them if they want to continue with an existing file, or overwrite it. Perhaps I was not clear enough. Steps 1-3 are already done by mozilla, but currently mozilla copies the file to its final location only once it has finished loading in its entirety. The other bug is discussing whether the file should be copied as soon as the user puts in the file location for saving to. Another suggestion on there was not to start downloading at all until the user has entered the file location. Either way, it is a good point to check for an existing file with the same name, and ask the user if they want to continue from the end of the existing file.

It's probably a moot point anyway now. Looks like they are just going to rename the file, and leave it where it is. I'm sorry if I got a bit sidetracked.

what is milestone "mozilla1.0" anyway? Moving to future.

Milestone "mozilla1.0" is a *point in time* just like any other milestone. I suggest to reset TM to "mozilla1.0". BTW. look at how GetRight does it. It's the best because aborted/forgotten downloads can be *doubleclicked to resume* from the *user selected location* (...\MyDownloads\filename.zip.moz).

*** Bug 94875 has been marked as a duplicate of this bug. ***

This may or may not be the place to bring up the idea of segmented downloading (a la getright). I thought it might be because it too just uses HTTP RANGEs. Yes anyway, I also think this a very important addition, but also very important is that it copes with them _well_ and is very flexible in that repect (`pause' buttons?), unlike earlier versions of netscape (4) which kinda pseudo supported resumable downloads. You never really knew whether it was going to work and on the rare occasions it did it was kinda like magic. I quite like the way IE for the mac handles its download manager IMHO. ...and I find that 90%+ of HTTP download sites and pretty much 100% of FTP servers support it.

how about bug 20851? seems that would be a good place to do the backend work, then once that is done this would (hopefully) be a interface addition only.

Adding dependency on the bug for temp folder saving. See my comments there for a suggestion to remove the temp folder for save to disk.

It would be great if people would quit bouncing the bugs around, adding dependencies, discussing implementation details and all...and maybe just start coding! This will go on forever - it already has. This one has been registered for almost TWO YEARS while it should be VERY simple to at least implement a SIMPLE version of this feature as I've said before...anything is better than nothing and can be extended later. Also note this "bug" has 31 votes now! Easy for me to say, maybe I should start working on my programming skills and do it myself... unfortunately I don't have the skills yet...I know some C and all but Mozilla source code is one big salad of pointers and naming conventions to me. I'll work on that, but don't expect to see useable results within the next few months.

Don't learn to code. Write a design spec for this feature and get it approved. Networking owns half the functionality of this feature, but for that half, I will file bugs and mark blockers for any design spec that is approved. I have given a lot of thought to these design issues, but not had time to put them all in writing due to higher priority problems. If you want help with this, I'll help you out.

btw, ben is working on a download manager, bug 25995, which might fix issues here.

*** Bug 112860 has been marked as a duplicate of this bug. ***

*** Bug 138664 has been marked as a duplicate of this bug. ***

*** Bug 155732 has been marked as a duplicate of this bug. ***

Has this bug been abandoned, or what? It hasn't been touched since 2001 and this would be a *very* nice feature to have.

Thats because this bug has been set to be fixed in the future so it isnt important rright now. It would be nice for some to start working on it again though because it is quite an important feature for modem user and even Cable/DSL user who are downloading big files. This would be a great addition for the next public Moz realese.

I would label any internet application that does not support resuming as crippled. It is unintuitive for a program to restart any interrupted download from the beginning. Not to spam, but of course there isn't rationale to be pushing this bug off more than it absolutely needs to be.

I agree with #62. It can't be THAT hard to implement, because Mozilla already does some resuming on it's own (but that's very unpredictable, imho). With 41 votes and 62 (now 63 :) comments, this is one of the bigger bugs, right?

If six more people add themselves to the CC list, this will qualify for bug 163993.

I am going to move this bug over the download manager. Some concerns raised here may be bettered solved if driven by an application requirement.

Well done. I guess we should declare a target milestone to have te capability to resume donwloads. Since the 1.4final will replace the 1.0 branch as stable development path, I think that we should take this as for target. Since this an old bug, and it's still one of the most voted, probably many people will agree that we have to resolve it as soon as possible. According to what I read, the Download Manager leaks of a great feature. C'ya.

There are voices that, if you own a copy of Download Accelerator, you can rename dapop.dll to npdap.dll and copy it to the plugins folder. Then, by clicking into properties in the Download Manager window, you'll be able to Pause/Resume the current download, but Mozilla mustn't be closed. Is it true? I think this should be interesting...

WORKAROUND: A simple and fast (but not complete) implementation/workaround would be adding 'Local filename' or 'Saved As' to Download Manager. Now you can do this via 'Show in Browser' button, which is less convenient (it works for 'Cancelled' downloads, I do not know if it works when Mozilla crashes and after exiting Mozilla). If Mozilla crashes and does not delete the temporary file then all that is to be done is 1. go to the directory where the partialy downloaded file is stored. 2. check the 'Location' field to see where the file was being downloaded from 3. use some download program with ability to resume downloads like 'wget -c', optionally using 'Save As' ('-O' option in wget) if the file was saved under different name.

This feature would also be very useful for sites which use some kind of cookie-protection for their downloads like Oracle.com, GameSpot.com etc. Esp. under Linux I don't know any way to resume such a download as the whole cookies , sessions etc. have to there to resume it, something that wget and d4x AFAIK can't do ;-)

*** Bug 173405 has been marked as a duplicate of this bug. ***

Tweaking summary for b.m.o. queries in an attempt to avoid all of the more recents dupes.

*** Bug 164878 has been marked as a duplicate of this bug. ***

I believe that this bug should be a blocker for whatever the final release of Mozilla will be that contains Seamonkey rather than Firebird. If implementing a resume function natively is too difficult, can we not just make Mozilla a front end for a bundled wget along the lines of "WackGet" at "http://www.millweed.com/projects/wackget/"? Or would licensing issues prevent supplying wget with Mozilla?

*** Bug 146168 has been marked as a duplicate of this bug. ***

Via bug 146168, downloads that have been "cancelled" due to Mozilla actually crashing, should appear in the queue on restart and be given the same status as manually cancelled downloads. (Comment 0 sugguest an automatic prompt to resume all cancelled downloads on a browser restart.) In terms of comment 16 (not making the scope of this bug too large for any work to be done) I suggest that the first priority is actually nailing down the technical ability to resume a cancelled download. Once that's done, this bug could be marked fixed and further development could be handled in separate bugs. However, for now, there should be a single bug open for resume issues so as to avoid the mass confusion of so many different bugs pointing to the same basic thing, but with minor variations.

*** Bug 213141 has been marked as a duplicate of this bug. ***

Does the scope of this bug include support for resuming a download when, for instance, switching to a different mirror when the one you're downloading from is proving to be just too darn slow? In any case, I'd like to see Moz.'s download procedure simplified as follows... 1. Dump the feature of starting the transfer before the destination is set. If a user is so easily distracted from specifying a destination for the download so often as to make this a useful feature for them, they would probably benefit in many areas of their life from getting medical assistance for this problem. For the rest of us, I for one am fine with losing that one download in a thousand or more I may be called away from by some emergency. Simplify, man! 2. Leave canceled partial files in place, with no renames or what have you. No need to remember the URL or anything either: as mentioned above, the user may have cancelled a slow download in order to try another mirror. (No more saying "Dang this is slow! Might as well let it finish, though, since it's gone this far. Sigh." Feel free to stop that slow download and resume from a faster source!) Since they're being left in place, there's also no need to have them in the cache stealing space from things you actually want cached. 3. If the location specified for a download already has the file there, offer to Resume, Replace, or Cancel. Perhaps also offer to let the user choose another target location immediately without having to retrigger the download procedure from the beginning. If it turns out the source file size is less than the existing file, tell the user about it. If it's bigger, let the user worry about it. They may be getting an update of a cumulative log file or something. A caution text in the Res/Rep/Can dialog will cover that sufficiently. Anyway, that's my idea of the right way to go. Simple. (Gawd. This bug is almost four years old and still marked as NEW. I feel like I'm in a supermarket. :) )

> Does the scope of this bug include support for resuming a download I would say no. We want to keep this as simple as possible - otherwise nothing will ever be accomplished. As per the summary and comment 0, we should only be concerned (at present) with implementing a resume feature. > Dump the feature of starting the transfer before the destination is set. See bug 55690 and bug 69938.

Er - I should have said "yes" above. It should support resuming with the same file from a different server if you manually cancel a download (keeping what you have) and pick up the remainder from a faster source. For some bizarre reason I'd read the question as "rename".

Regarding Comment 77 "...Dump the feature of starting the transfer before the destination is set..." --> I know many people that have commented that they prefer this behaviour over that in IE. This feature is great for saving download times: For Example: I visit www.mp3.com on a regular basis, and download MP3s (15-40 at a time). Unfortunately the site only allows two simutaneous downloads. What I do is start download 1, and download 2, then I click the link to queue up download 3, and I go along with my regular business (ie: checking mail, working on documents, etc) Eventually one of the downloads will complete, and in the period of time (5-40sec.) it takes me to finish my last thoughts, and set the destination to save the file - the 3rd download is already 3/4 complete.

One of the features needed for resuming a download is that it should not depend on the IP address of the downloader. I've paused a download (using Netscape downloader), gone offline so the phone could be used for a voice call, went online again and could not continue the download because my internet service assigned me a different IP. For purposes of making a partial download compatible with other downloading programs, the partial file should not have any info prefixed to it, such as filesize and date. As someone posted earlier, that info should be in a separate log of download activity. A log of downloads should have the URL of the server, the path/filename of the local destination, and the path/filename of the temporary download file if used, as well as file size and date info for these.

*** Bug 222118 has been marked as a duplicate of this bug. ***

Why not using something equivalent to SmartDownload produced by Netscape? This worked fine with Netscape 4.x.

Mozilla really needs this feature. When i sometimes download a file, Mozilla downloads a part, then mark this chunk as a "finished download". Yup, i think that this is already a bug (i forgot the number), and by this reason (and some users can't pay a license for use GetRight or similar), this feature must be implemented. It will save time (and money too) to users. I'm a modem user (and using a **** modem), and i don't like to use getright (shareware, sometimes crashes, and steals too many memory). And free download managers does not fix issue too. Installing a plugin is not the solution. For example, you cannot launch a local-stored executable or zipfile, instead, mozilla (and any browser that uses that plugins) sends the URL to plugin, and this gives an "ONLY HTTP AND FTP's!" error, preventing the user to launch the file. Mozilla already have a Download Manager, 50% functional (it records all your downloads, and can do basic pause/resume). Now is time to build the another 50% (resume broken downloads, cancel a download for resume later, and this .MOZ partial chunks thing) I cast my vote here... i want this feature too... because i don't have $24.95 for purchase GetRight, and for a 200KB - 5MB file, it is useless.

Mozilla really needs this feature. When i sometimes download a file, Mozilla downloads a part, then mark this chunk as a "finished download". Yup, i think that this is already a bug (i forgot the number), and by this reason (and some users can't pay a license for use GetRight or similar), this feature must be implemented. It will save time (and money too) to users. I'm a modem user (and using a **** modem), and i don't like to use getright (shareware, sometimes crashes, and steals too many memory). And free download managers does not fix issue too. Installing a plugin is not the solution. For example, you cannot launch a local-stored executable or zipfile, instead, mozilla (and any browser that uses that plugins) sends the URL to plugin, and this gives an "ONLY HTTP AND FTP's!" error, preventing the user to launch the file. Mozilla already have a Download Manager, 50% functional (it records all your downloads, and can do basic pause/resume). Now is time to build the another 50% (resume broken downloads, cancel a download for resume later, and this .MOZ partial chunks thing) I cast my vote here... i want this feature too... because i don't have $24.95 for purchase GetRight, and for a 200KB - 5MB file, it is useless.

Improved downloading would be nice. I tried fetching a 13Mb file recently from a server that may have been impatient with my slow dialup connection, and only got 2 Mb of it with Mozilla. There's a downloader called Go!zilla 3.5 that works very well, and I got the file with that. But it's old, and only knows about IE and Netscape. It won't intercept Mozilla FTP. Later versions not only are likely to have that limitation, but are far more full of adware than Go!zilla 3.5. Sun Microsystems has a free Java-based downloader, but I haven't checked out its capabilities. But if Mozilla had quittable and resumable downloading, that would be much more convenient than manually passing file info to another program that can pause, go offline, shut down for a few days, and then resume.

Improved downloading would be nice. I tried fetching a 13Mb file recently from a server that may have been impatient with my slow dialup connection, and only got 2 Mb of it with Mozilla. There's a downloader called Go!zilla 3.5 that works very well, and I got the file with that. But it's old, and only knows about IE and Netscape. It won't intercept Mozilla FTP. Later versions not only are likely to have that limitation, but are far more full of adware than Go!zilla 3.5. Sun Microsystems has a free Java-based downloader, but I haven't checked out its capabilities. But if Mozilla had quittable and resumable downloading, that would be much more convenient than manually passing file info to another program that can pause, go offline, shut down for a few days, and then resume.

Hi, I am using not so fast 64kbps ISDN connection and the sheer size of tar balls, etc. that today's software patches and evaluation copies, etc. is now overstretching the line capacity. (Sun's Star Office (aka Star Suite in Japan due to a conflict with other software product name) needs patches that is often about 30MB or more.) Often, a large file download is stopped to some unknown reasons after a couple of hours, etc.. It is easy to restart such interrupted download using IE 6.x under Windows. If I use mozilla, the download is not restartable. (This is true under linux, too.) This is partially because the file is stored in temporary location and the name for that temporary file is not quite carried over to the next dowload attempt. (I am posting this using netscape 7.1 BTW). Please see bug 69938 on this filename and storage area topic. Like others who posted here, I really would like to see the restarting feature of previously interrupted download. netscape 4.x on OS/2 could do it and I believe also under windows 9x. So why not with mozilla ?

Definitely an annoyance when one forgets that a download is in operation, closes the browser and there is no warning that a download is about to be disconnected.

Neil: agreed, but that's bug 28385.

*** Bug 235568 has been marked as a duplicate of this bug. ***

this bug is assigned for the mozilla trunk. Will it be fixed for firefox also? Firefox has a new download manager with a resume button, but that doesn't work correctly.

this bug is assigned for the mozilla trunk. Will it be fixed for firefox also? Firefox has a new download manager with a resume button, but that doesn't work correctly.

firebird will need a separate patch, the download code there is all different.

Any chance to see this bug fixed in the Mozilla Suite?

sure, but not in 1.7. If for no other reason, because this will most likely require new localizable strings and there is a localization freeze between beta and final.

Not going to block the release on a feature request that would require significant change to localizable strings.

*** Bug 238229 has been marked as a duplicate of this bug. ***

*** Bug 239326 has been marked as a duplicate of this bug. ***

Bug 131871 - Implement a way to prevent the loss of downloads when mozilla crashes

*** Bug 241689 has been marked as a duplicate of this bug. ***

describes how I'm going to implement this. comments welcome.

> 1.1 > ... > ASCII Art for the new toolbar (linux): > [Properties] | [Cancel] [Resume] [Remove from list] | [Show file location] > or: > [Properties] | [Cancel] [Pause] [Remove from list] | [Show file location] or (for already finished files) [Properties] | [Cancel] [Reget] [Remove from list] | [Show file location] > 2.1 > Cancelling the download of a file will leave the partial file intact. Hope this is also true when the user (accidentally) eg. does Ctrl-Q so he can resume later one. > 2.3 > Selecting a cancelled download and clicking "Resume" will either: > o) Change the state to "Downloading", continuing where the download left off > o) or show a message along the lines of "This server does not support > resuming downloads" If server does not allow resuming please ask the user to start the whole download again.

shouldn't the message saying the server doesn't support resuming come when you actually pause/cancel it? because when you resume and then see the message it doesn't matter anymore and you have to restart the whole download anyway. Or maybe a a field with the text "resumable" or "not resumable" or something like that next to the download? that way, you know if you have to restart before you cancel it.

hmm. those are good points. When you press Cancel, you should really not get a message about resuming, imo, because you were cancelling it. When you Pause... This will probably be implemented by just stopping reading from the socket, so this will be resumable in basically all cases. (unless you wait too long, in which case it sends a byte-range request). But you made a good point, and in some cases it's possible to know that the download won't be resumable, and in those cases the button text should say "Reget". (In reply to comment #103) > Hope this is also true when the user (accidentally) eg. does Ctrl-Q so he can > resume later one. absolutely. Thanks for those comments!

Minor point, but I'm not sure "reget" is a word; this should probably be "get again," "restart" or the like. It can be hyphenated (re-get) if desired. You could also add a "check for upgrade" that compares the date, filesize, CRC, or some other parameter, though this may be a different RFE.

2.2 After a restart of Mozilla, the displayed state of the downloads that were neither in progress nor paused is unchanged. (a) Downloads that were in progress show up as "Cancelled". (b) Downloads that were paused also show up as "Cancelled". XXX is that a good idea? will this confuse users? I think in (a) "Interrupted" instead of "Cancelled" would be more explicit. "Cancelled" sounds like something lost. And in (b) why not keep "Paused"? Also, in the case of a server which is known as not supporting resumable downloads, a warning should be visible as soon as possible (before cancelling a download). It is very annoying to start downloading a large file and realizing after 20 Mb that you cannot resume your download (especially when having a 56K connection).

Perhaps [Remove from list] should be renamed to [Remove] and do the following: (1) If the download is completed, remove the list-entry (2) If it's a partial download, delete the .part file and remove the entry. Perhaps it should be called [Remove] and [Delete] ? Or it could be made so that if you Shift+Click on the button it also deletes the .part file (if any). I don't think it's a good idea to have a non-"destruction" action in the middle of two that do: [Cancel] [Pause] [Remove] It's better to position Pause far to the left, like: [Pause] [Cancel] [Remove] If the server is known not to support resumable downloads, the [Pause] button should just be greyed out. Is this something that is known beforehand ? I know mozilla keeps a hidden pref that contains all the servers that need some sort of HTTP "hack" - can something similar be done with servers that support resume or not? Or can you query the server in some way? In the case of cancelled, paused, failed or finished downloads, the [Pause] button should be renamed to [Download again]. Could you also make it so that the properties window can be shown even if a download is not in progress with this patch ? I'm not sure if it's a major codechange or not. The only reason is that I'd like to be able to copy the URL :) Or a "Copy URL Location" could be added to the context-menu - but I like it slim.

>>Minor point, but I'm not sure "reget" is a word; this should probably be "get >>again," "restart" or the like. It can be hyphenated (re-get) if desired. Perhap "Retry" but that could be confusing for some users.

Quote from this article about WindowsXP SP2: http://news.bbc.co.uk/2/hi/technology/3889353.stm "The update service includes downloading technology that will allow users to download the file bit by bit, a feature that would be useful for those with dial-up internet connections." I didn't hear about this before, just wanted to let you know.

*** Bug 257159 has been marked as a duplicate of this bug. ***

Even something as simple as a "try again" option or "re-try". There are times when a download fails and you just want to try to download it again. This would be a start towards resumable downloads. I have to agree with some comments I've read on this subject. If you want a full featured download manager then use one. There are many out there and they work quite well. For the most part I don't need one. But, being able to re-try a failed download would just be too sweet.

I have needed this feature many times in my years of downloaing programs. The larger the download the more valuable it becomes to a dial-up user. I would think this would draw quite a few dial-up users away from IE. Since then I have come across a feature in OSX called "Curl". An example is at http://www.planamesa.com/neojava/en/download.php . It works quit well. This should be easy to add to Mozilla. At least for the OSX version.

It would be nice that if Firefox find the same file on disk, to try to resume, or ask what to do: "delete the file and start downloading again" or "resume the file"

There's a program called Star Downloader www.stardownloader.com that has free versions, but the copy I have (v. 1.42) doesn't automatically integrate into Mozilla/Seamonkey/Firefox. I found a way to do it by hand but wouldn't expect every user to try that. Some downloaders including Star can set up multiple connections to sites and make themselves a nuisance. They hog the system and impede other network traffic. It would be better to have ability to resume built into a browser.

*** Bug 323558 has been marked as a duplicate of this bug. ***

A resume-function should be implemented at least when a connection is lost. This can happen "alot" when there is (especeially)a wireless network. The resume function is a bit unstable but most of the time it works. But not when a connection is lost.

(In reply to comment #114) Yes Yes Yes! BTW, there's no need for a new UI, just another item on the the list which now includes open with / save to disk / etc. - instead of "save to disk" we would have "save to disk (overwrite)" and "save to disk (resume)".

From the summary, this looks like a meta bug. However, it doesn't have the meta keyword, and it also has a number of things filled in that don't really make sense to a meta bug (like a target milestone, and attachments that appear to be talking about a specific feature proposal). I've noticed that the original title is "[RFE]resuming stopped downloads", and on 2001-06-05 it was changed to "[RFE] general issues w/ resumable downloads (ftp+http)" before growing to what it says now. What exactly _is_ this bug report about? We ought to clean things up a bit.

Okay, perhaps the summary should be changed to something like the following: ability to recommence a download that has not previously been successful And the clarification of what 'recommence' and 'not previously successful' means can be done in the comments.

To me, "recommence" would imply starting all over again, which is surely what we want to avoid? "Not previously successful" could cover a number of causes of the download not being completed: - the server dropped the connection - the ISP dropped the connection - the browser or OS crashed - a power failure - the user accidentally disconnected - the user accidentally cancelled the download - the user stopped the download because there wasn't time to finish it, to free up the phone line, or because it isn't worth running up a huge phone bill ....

No comment in a year and a half. Resetting A+QA on the assumption that they aren't current anymore. If I assumed wrong, please change back.

P.S. "Target" moz1.8a1 is obsolete as a "trunk" version. Resetting to ---

From the current POV, this at least depends on using the new toolkit download manager that has cross-session resume capability, SeaMonkey will switch to that in bug 381157.

Is there any similar bug as this one but focused on Firefox or the toolkit instead of the MozAppSuite?

Not sure about the bug numbers, but AFAIK, this is basically solved in some way in toolkit 1.9 and Firefox 3.

Currently (Firefox 3 RC 1), interrupted downloads cannot be resumed, only paused ones. This can be annoying, if, for example you are downloading a CD-ROM image over a 56K connection, and your modem connection is lost for some reason. If I pause the download, disconnect my network connection, reconnect my network connection, and then resume the download everything works well. If, however, I disconnect my network connection without warning firefox, then my download shows up as failed and I cannot resume it. Should I report this is a separate bug?

(In reply to comment #127) > Should I report this is a separate bug? No, because it is already reported and this bug depends on the other one: https://bugzilla.mozilla.org/show_bug.cgi?id=87151

I think as much of this as can be done has been resolved in SeaMonkey specifically with switching to toolkit download manager in bug 381157, so duping to that one. Please file any specific bugs that still exist against the backend in toolkit.