164878 - Ability to restart/resume cancelled/failed downloads

Status: VERIFIED DUPLICATE of bug 18004

(SeaMonkey :: Download & File Handling, enhancement)

Description

[David Eccles]

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?

Comment 1

[Olav Vitters]

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

Comment 2

[Olav Vitters]

no its not

Comment 3

[Olav Vitters]

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 ***

Comment 4

[Olav Vitters]

I really should go to bed... :-((

sorry for all the spam.. 

Comment 5

[David Eccles]

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...

Comment 6

[Daniel Wang]

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

Comment 7

[David Eccles]

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.

Comment 8

[Olav Vitters]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

see bug 146168

Comment 10

[David Eccles]

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...

Comment 11

[Christopher Aillon (sabbatical, not receiving bugmail)]

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

Comment 12

[Robert Wall]

Duplicate of bug 131780?

Comment 13

[David Eccles]

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

Comment 14

[Michael Lefevre]

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

Comment 15

[Michael Lefevre]

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...)

Comment 16

[Frederik Reiss]

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

Comment 17

[David Eccles]

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.

Comment 18

[Asa Dotzler [:asa]]

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

Comment 19

[Brian 'netdragon' Bober]

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

Comment 20

[Brian 'netdragon' Bober]

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.

Comment 21

[Bradley Baetz (:bbaetz)]

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

Comment 22

[WD]

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

Comment 23

[warren crossing]

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! 

Comment 24

[Graham Murray]

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.

Comment 25

[David Eccles]

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.

Comment 26

[Matthias Versen [:Matti]]

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

Comment 27

[Wolfi]

> 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.

Comment 28

[kenneth]

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...

Comment 29

[Heiner Steven]

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?

Comment 30

[David Eccles]

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).

Comment 31

[James Siddle]

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

Comment 32

[Sander]

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

Comment 33

[Jo Hermans]

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

Comment 34

[Matthias Versen [:Matti]]

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

Comment 35

[Eric Gerlach]

Is this a dupe of bug 18004?

Comment 36

[David Eccles]

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]

Comment 37

[Jason Bassford]

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 ***