general issues w/ resumable downloads (ftp+http) - ability to manually/automatically restart/resume cancelled/failed/disconnected downloads

RESOLVED DUPLICATE of bug 381157

Status

SeaMonkey
Download & File Handling
--
enhancement
RESOLVED DUPLICATE of bug 381157
19 years ago
3 years ago

People

(Reporter: Matt Schmitt, Unassigned)

Tracking

(Blocks: 1 bug)

Dependency tree / graph
Bug Flags:
blocking1.7 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

19 years ago
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.

Updated

19 years ago
OS: Mac System 8.6 → All
Hardware: Macintosh → All
Summary: [RFE]resuming stopped downloads
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.

Updated

19 years ago
Assignee: leger → gagan
Component: Browser-General → Necko
QA Contact: leger → tever

Comment 2

19 years ago
Setting QA Contact/Component

Updated

19 years ago
Target Milestone: M15

Updated

19 years ago
Assignee: gagan → valeski

Comment 3

19 years ago
FTP RFE => Jud

Comment 4

19 years ago
Bulk move of all Necko (to be deleted component) bugs to new Networking

component.

Comment 5

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

Comment 6

18 years ago
adding Bill Law to the cc list as this involves UI/download dialog changes. I
need to add the FTP protocol ability.
Status: NEW → ASSIGNED
Target Milestone: M15 → M17

Comment 7

18 years ago
Moving post beta bugs to M18 which is now the post-beta milestone.
Target Milestone: M17 → M18

Comment 8

18 years ago
This is a dupe of bug 40265.

Comment 9

18 years ago
*** Bug 40265 has been marked as a duplicate of this bug. ***
*** Bug 34548 has been marked as a duplicate of this bug. ***
Keywords: helpwanted

Comment 11

18 years ago
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.

Comment 12

18 years ago
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.

Comment 13

18 years ago
-> gagan
Assignee: valeski → gagan
Status: ASSIGNED → NEW

Comment 14

18 years ago
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.

Comment 15

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

Comment 16

18 years ago
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!

Comment 17

18 years ago
I just wanted to file a dupe. I cc myself, since I want to see this feature...
Target Milestone: M18 → ---

Comment 18

17 years ago
I believe dougt already has one for FTP resume.
Assignee: gagan → dougt
Target Milestone: --- → mozilla1.0

Comment 19

17 years ago
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.
Keywords: 4xp, mozilla1.0

Updated

17 years ago
Blocks: 75364
*** Bug 76886 has been marked as a duplicate of this bug. ***

Comment 21

17 years ago
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

Comment 22

17 years ago
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

Comment 23

17 years ago
shhhh.  don't let the pointy heads hear about this....  :-)

Lets see if I can get something to work for 0.9.1....  
Status: NEW → ASSIGNED
Keywords: helpwanted
Target Milestone: mozilla1.0 → mozilla0.9.1

Comment 24

17 years ago
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...
Target Milestone: mozilla0.9.1 → mozilla1.0

Comment 25

17 years ago
mass move, v2.
qa to me.
QA Contact: tever → benc

Comment 26

17 years ago
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...)

Comment 27

17 years ago
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.

Comment 29

17 years ago
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'.

Comment 30

17 years ago
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?

Comment 31

17 years ago
Then this needs to be dependant on bug 55690.

Comment 32

17 years ago
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]

Comment 33

17 years ago
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)

Comment 34

17 years ago
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.

Comment 35

17 years ago
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.

Comment 36

17 years ago
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).

Comment 37

17 years ago
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.

Comment 38

17 years ago
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).

Updated

17 years ago
Keywords: mostfreq
Summary: [RFE]resuming stopped downloads → [RFE] general issues w/ resumable downloads (ftp+http)

Comment 39

17 years ago
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.

Comment 40

17 years ago
Created attachment 37208 [details]
An illustration of what the dialog might look like

Comment 41

17 years ago
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.

Comment 42

17 years ago
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.

Comment 43

17 years ago
I disagree, the core issues are completely different.

Comment 44

17 years ago
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.

Comment 45

17 years ago
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?

Comment 46

17 years ago
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.

Comment 47

17 years ago
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.

Comment 48

17 years ago
what is milestone "mozilla1.0" anyway?  Moving to future.
Target Milestone: mozilla1.0 → Future

Comment 49

17 years ago
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. ***

Comment 51

17 years ago
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.

Comment 52

17 years ago
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.

Comment 53

17 years ago
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.
Depends on: 55690

Comment 54

17 years ago
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.

Comment 55

17 years ago
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.

Comment 57

17 years ago
*** Bug 112860 has been marked as a duplicate of this bug. ***
Depends on: 98288, 107552

Updated

16 years ago
Blocks: 129923

Comment 58

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

Comment 59

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

Comment 60

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

Comment 61

16 years ago
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.

Updated

16 years ago
Blocks: 92997

Updated

16 years ago
Summary: [RFE] general issues w/ resumable downloads (ftp+http) → general issues w/ resumable downloads (ftp+http)

Comment 62

16 years ago
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.

Comment 63

16 years ago
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?

Comment 64

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

Updated

16 years ago
Blocks: 163993

Updated

15 years ago
Keywords: mozilla1.0

Comment 65

15 years ago
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.
Assignee: dougt → blaker
Status: ASSIGNED → NEW
Component: Networking → Download Manager
QA Contact: benc → petersen

Comment 66

15 years ago
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.

Comment 67

15 years ago
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...

Comment 68

15 years ago
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.

Comment 69

15 years ago
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 ;-)

Comment 70

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

Comment 71

15 years ago
Tweaking summary for b.m.o. queries in an attempt to avoid all of the more
recents dupes.
Summary: general issues w/ resumable downloads (ftp+http) → general issues w/ resumable downloads (ftp+http) - ability to manually/automatically restart/resume cancelled/failed/disconnected downloads

Comment 72

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

Comment 73

15 years ago
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?
Blocks: 171142

Comment 74

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

Comment 75

15 years ago
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.

Comment 76

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

Comment 77

15 years ago
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. :) )

Comment 78

15 years ago
> 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.

Comment 79

15 years ago
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".

Comment 80

15 years ago
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.

Comment 81

15 years ago
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.

Comment 82

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

Comment 83

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

Comment 84

15 years ago
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.

Comment 85

15 years ago
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.

Comment 86

15 years ago
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.

Comment 87

15 years ago
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.

Comment 88

15 years ago
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 ?


Comment 89

14 years ago
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.

Comment 90

14 years ago
Neil: agreed, but that's bug 28385.
*** Bug 235568 has been marked as a duplicate of this bug. ***

Comment 92

14 years ago
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.

Comment 93

14 years ago
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.

Assignee: firefox → cbiesinger

Comment 95

14 years ago
Any chance to see this bug fixed in the Mozilla Suite?
Flags: blocking1.7?
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.

Comment 97

14 years ago
Not going to block the release on a feature request that would require
significant change to localizable strings. 
Flags: blocking1.7? → blocking1.7-

Comment 98

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

Comment 99

14 years ago
*** Bug 239326 has been marked as a duplicate of this bug. ***
Priority: P3 → P1
Target Milestone: Future → mozilla1.8alpha

Comment 100

14 years ago
Bug 131871 - Implement a way to prevent the loss of downloads when mozilla crashes
Depends on: 131871

Comment 101

14 years ago
*** Bug 241689 has been marked as a duplicate of this bug. ***
Created attachment 149119 [details]
ui spec

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.

Comment 104

14 years ago
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!

Comment 106

14 years ago
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.

Comment 107

14 years ago
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.

Comment 109

14 years ago
>>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.

Comment 110

14 years ago
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. ***
Product: Browser → Seamonkey

Comment 112

13 years ago
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.

Comment 113

13 years ago
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.

Updated

13 years ago
No longer blocks: 163993
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"

Comment 115

13 years ago
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.

Comment 116

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

Comment 117

12 years ago
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.

Comment 118

12 years ago
(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)".

Comment 119

12 years ago
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.

Comment 120

12 years ago
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.

Comment 121

12 years ago
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
....

Updated

12 years ago
Depends on: 87151

Updated

11 years ago
Blocks: 372972

Updated

11 years ago
Whiteboard: CON-007a

Updated

11 years ago
Whiteboard: CON-007a

Updated

11 years ago
No longer blocks: 372972
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.
Assignee: cbiesinger → nobody
QA Contact: chrispetersen → download-manager
P.S. "Target" moz1.8a1 is obsolete as a "trunk" version. Resetting to ---
Target Milestone: mozilla1.8alpha1 → ---

Comment 124

10 years ago
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.
Depends on: 381157
Is there any similar bug as this one but focused on Firefox or the toolkit instead of the MozAppSuite?

Comment 126

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

Comment 127

10 years ago
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?

Comment 128

10 years ago
(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

Comment 129

9 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 381157
You need to log in before you can comment on or make changes to this bug.