User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.1) Gecko/20020826 Forgive me if I am wanting the Download Manager to look too much like GetRight... I noticed that when I clicked the cancel button in the download manager, there was no confirmation of my cancelling. Usually, I would not be annoyed at this, but there was not way to undo the cancel. Once a file has been cancelled, there seems to be nothing available in the Download Manager to re-download the file. Compare this to pause / resume. Once a file has been paused, it can be resumed again at some later time. One possible situation this could happen would be if there were two similar programs, one with a large file, one with a small file. Both files start downloading at a similar time, then once the small file has completely downloaded, the large file is cancelled. After finding out that the smaller program is not what was expected, it would be nice to start the large download again. Hm... perhaps there are two bugs in this. Reproducible: Always Steps to Reproduce: 1. start a download of a file 2. click cancel, or cancel the download in some way 3. attempt to un-cancel the download Actual Results: Inactivated buttons (properties / cancel) did not work. Expected Results: Inactivated buttons should obviously not work, but something in their place would be a nice touch. I expected a "start" button, or similar, or a confirmation of the cancel operation. A semi-workaround would be to pause every download, instead of cancel. But then, what's the use of cancelling downloads?

*** This bug has been marked as a duplicate of 143072 ***

no its not

Could be dupe of bug 98288. That bug is http-only, but I saw a bug somewhere about ftp resume support (backend, UI hasn't been implemented). *** This bug has been marked as a duplicate of 32108 ***

I really should go to bed... :-(( sorry for all the spam..

You missed bug 42872... that is probably the closest to this bug. Perhaps this bug should only consider the "undoing" part of the cancel process. I guess that when the download dialog in bug 42872 is fixed, the confirmation part of this bug will be fixed. Alternatively, put in a dependancy...

alright, the only thing left not dupe of anything is the ability to resume a cancelled (not paused) download.

Does this mean there is another bug that mentions cancelling a download in the Download Manager? Sorry for being overly pedantic, but bug 42872 is not related to the Download Manager.

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

see bug 146168

I realised that bug 42872 may be related to the Download Manager (I contradicted myself), but it does not mention the Download Manager in the bug. Well, going on your consideration that the original bug was a dupe of bug 42872, this bug should be considered a dupe of bug 146168. Actually 146168 more so, because it actually mentions the download manager (unlike 42872). However, that talks about resuming on startup, where this bug is resuming any time...

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

Duplicate of bug 131780?

bug 131780 indicates pause / resume, not cancel / start as I intended in my original report.

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

seems to me from the discussion here that this isn't really a dupe of anything existing, and there's a similar request in bug 167668, which I just duped to this. to clarify: what this bug is now about is the ability to restart (from the beginning) a download which has been cancelled by the user, or which failed, or which succeeded and has subsequently been deleted. that is, from the list of downloads in the download manager, an option to tell mozilla "take the URL from this previous download and start downloading it again". not sure anyone will be in a hurry to implement this, but other download managers have this feature, so it seems like a legitimate RFE. confirming. (David - I hope I haven't completely misrepresented what you were looking for here, if I have, please jump on me...)

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

Your changes were good, the description fits the bug much better now. Again, not quite the same bug, but probably closer than other bugs I have noticed. The difference being this bug allows restart at any time (but possibly not if the download has been finished), while the other bug is only for a finished download.

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

I'm marking this bug as dependant upon bug 98288 only because it is for failed download, and not paused ones.

If was in error thinking the ability to restart/resume cancelled/failed downloads depends on the ability to resume http downloads, please remove the dependancy.

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

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

hmmm, I am doing a bug hunt for "failure of downloads" in the download manager and have come across some interesting stuff - allow me i am using build 2002121217 and its great.. but ocassionally i notice that when the bandwidth (bw) goes from very fast to very slow ( yes i have a stupid connection) the download fails (1854677) and sometimes a page does not load similar to 124133. is this almost a problem with timeouts ?? something just goes ok "connection/server gone" as for uncancel (what a stupid name) this should be easy to hack up very quickly - just steal some code from pause/resume and stick it in the download manager.. but i think this is not totally nessecary - please. cancled is cancled - suspend/resume and pause/play postpone/later on etc. what would be very nice it to have the file url retrievable maybe like "copy link location" so i can then resume it manually or paste it into curl.. yeah go the free world!

I am not concerned so much about resume cancelled downloads, but I would really like to be able resume/continue failed downloads without having to completely restart.

Check back with the original bug report to see a possible situation where wanting to restart a cancelled download might be useful. This bug has been flagged as an enhancement, so has already been considered to be 'not completely necessary'. The file URL is already retrievable from the 'Source' column, and according to comment 15, the fix for this bug/enhancement will use the stored URL. If you have comments or questions about other bugs, they would be more helpful in the comments for those bugs.

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

> I am not concerned so much about resume cancelled downloads, but I would really like to be able resume/continue failed downloads without having to completely restart. I absolutely second Grahams view. It' s one of the most annoying non-features in Mozilla's download capabilities, that broken/interupted/disconnected d/ls: -a) don't automatically continue after the connection to the file source is reestablished -b) cannot reuse the the already retrieved chunk and continue to get only the missing pieces of it, rather than only offering a 'Cancel" button in the d/l window, forcing the d/l to start from scratch over and over again, for any more time it doesn't complete. This game is particulary funny, if one tries to d/l afiles of some 10+ MB on a dial-up connection with frequent line-breaks. WGet and other specialized d/l-managers, that really deserve this name, are doing what thei name indicates. Mozilla yet doesn't. Here Mozilla still has to learn quite a bit, before growing up.

even opera have this one right:) (one of the reasons i have it installed) its a pain to sit on a dialup and not being able to resume a broken download maybe as you have to use the phoneline for other stuff or it dies or a number of other reasons why you want to have builtin resume in a browser. ie have it to an extent, you have to dig up the original link/file and its may resume. given that mozilla have a deedicated download manager window i dont see the problem, just have it store the link and maybe the refer (some sites dont like you downloading from a link not on theyre own pages). hell, if i had a clue about how to code this in i would do so myself...

My initial bug report (187637) was closed as a dup of this one. Unfortunately this bug intermingles two completely different problems: (a) having a way to continue with interrupted downloads: if a download completed up to 95%, there should be a way to just retrieve the missing 5% of a file. Currently, the download restarts with byte 1. (b) having a GUI element allowing for another retrieval of a file that's already present in the download manager file list. My main focus was on (a). If it is implemented in the download manager, fine. If I have to enter "mozilla --remote continueDownload(ftp://xxxx/file)", well, I could live with that, too. I just want a way to continue interrupted downloads -- anyhow. Is this bug really the right place for this, or would it be better to re-open 187637?

Based on comment 13 and comment 15, there is probably another open bug with the same resume feature that you wanted (like bug 131780, or a child bug of this, bug 173405). I had probably ignored the "resume" part of this bug description, but now it is pointed out perhaps the description should be changed. But then again, since this bug blocks other bugs, perhaps the current generic description would be more appropriate. By this bug's description, your two "completely different" cases are combined in this bug (which if you consider the "/"s includes four different cases).

I'm new to this so please be gentle... As a dialup user, the lack of a resume option for failed/disconnected/etc downloads feels more like a bug than a possible enhancement. It took me four attempts to download Mozilla 1.4b, and I'm currently on attempt no.2 for KDE 3.1.2. That amounts to most of my weekend and a costly bill for ordering pizza on my mobile.... Additionally, if the download manager is unable to resume a download, then surely this should at least be indicated in the list? If a download fails, then the download manager screen gives all the indications of being able to resume (i.e. the progress bar is still displayed & you can open a progress window with options) but when you try to make the download resume, nothing happens and it feels like a bug. Jim

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

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

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

Is this a dupe of bug 18004?

Yes, this could be a dupe of bug 18004 (wow, 5-figures). I have a feeling the other bug was started before there was a Download Manager (bug 18004, comment 14), and the component was changed. It seems to give a better idea of what to do for resolving the bug. It mentions only resuming in the description, but cancelling is suggested in the body of the bug. [Interesting... almost all of the comments in this bug refer to dupes]

Duping to bug 18004 - it's obviously what this bug, and bug 173405, intended on addressing. (The cancel without confirmation that was originally part of this bug has already been addressed some time ago by bug 42872. Remaining issues are the same as bug 18004.) *** This bug has been marked as a duplicate of 18004 ***