303158 - dl manager needs an easier way to attempt a new download for canceled or interrupted downloads

Status: RESOLVED INCOMPLETE

(Camino Graveyard :: Downloading, defect)

Description

[Mike Pinkerton (not reading bugmail)]

spun off from 187483 which morphed to pause/resume downloads:



would it be possible to implement an easier way to restart (or just retry) a
canceled or interrupted download from the download manager?

right now it's a multistep process:

1. initiate a download (eg, d/l a chimera or mozilla build) which brings up the
download manager window.

2. stop the download: hit the Cancel button (or somehow disconnect your network
connection ;).

3. retry the download: you need to first copy the contents of the Source field
(expanded d/l entry)...

4. ...then paste the source url into the urlbar (Location field) of a browser
window, then hit return.

results: the download starts again (expected), but another entry is added to the
d/l mgr window (kind of cluttering).

Comment 1

[Bruce Davidson]

One possible UI suggestion (which UI designers should feel free to shoot down in
flames) would be to make the "Cancel" button toggle to "Reload" (or some such
wording) on a cancelled or failed download. We could use the same icon as on the
main toolbar.

Comment 2

[Nick Kreeger]

Bruce,

That is the plan.. I am going to work on this as soon as I finish up bug 187619

Comment 3

[Nick Kreeger]

Taking

Comment 4

[Simon Fraser [no longer active]]

Also have an item in the context menu. I'd suggest "Restart" as the verb here.

Comment 5

[Nick Kreeger]

Attachment: Patch 1

Just getting a working version of my patch up here. I moved the SaveInternalURI function out of CHBrowserView to CHBrowserService to make it accessible to an object that doesn't rely on a browser view instance to fire up a file->save download. 

Simon, does this statergy look ok?

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Just to clarify, this bug is for initiating an entirely new download based on the url stored with an interrupted or cancelled download.

Resuming downloads (picking up from where they left off, using the .part files) is bug 215343.

(Since some servers don't support resuming, we'll need the capability of this bug, too.)

Comment 7

[Nick Kreeger]

Servers that are running HTTP1.1 will be able to resume. On servers that are running HTTP1.0, a UI notice will need to be displayed that the download cannot be resumed.

Comment 8

[Chris Lawson (gone)]

Simon, would you mind responding to Nick's comment 5?

Stuart, can you take a look too sometime soon-ish?

Personally, I'd really like to see this in 1.1.

cl

Comment 9

[Nick Kreeger]

The best way to do this requires a good deal in code change before this happens. I doubt it will make 1.1

Comment 10

[Chris Lawson (gone)]

(In reply to comment #7)
> Servers that are running HTTP1.1 will be able to resume. On servers that are
> running HTTP1.0, a UI notice will need to be displayed that the download cannot
> be resumed.

We should probably just restart the download from the beginning in that case, rather than throwing an alert dialog, since re-downloading the file is what the user just asked to do.

I would personally suggest "Resume" as the CM action verb for "interrupted" downloads and "Restart" for cancelled downloads. (We can differentiate between them, obviously, or we wouldn't be able to put different status text in the manager.)

cl

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Comment 12

[Nick Kreeger]

(In reply to comment #10)
> (In reply to comment #7)
> > Servers that are running HTTP1.1 will be able to resume. On servers that are
> > running HTTP1.0, a UI notice will need to be displayed that the download cannot
> > be resumed.
> 
> We should probably just restart the download from the beginning in that case,
> rather than throwing an alert dialog, since re-downloading the file is what the
> user just asked to do.
> 
> I would personally suggest "Resume" as the CM action verb for "interrupted"
> downloads and "Restart" for cancelled downloads. (We can differentiate between
> them, obviously, or we wouldn't be able to put different status text in the
> manager.)
> 
> cl
> 

THe interfaces exist for resuming an "interrupted" (during an application session) download, and would be an easy hook-up. The problem is, at least according to a wiki dev doc, the interfaces aren't frozen... I'll try checking into this.

Ideally we should file another bug, one for interrupted downloads and one for cancelled.

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Resuming stopped downloads from where they left offf is bug 215343.

This is about starting a download completely over just from the manager (i.e., without having to ctrl-click the cancelled/interrupted download, copy the url, and paste the URL into the location bar again).