Closed Bug 131780 Opened 22 years ago Closed 15 years ago

download manager has no PAUSE button, only CANCEL

Categories

(SeaMonkey :: Download & File Handling, defect)

Product:
SeaMonkey
Component:
Download & File Handling
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 472001
Milestone:
mozilla1.2alpha

People

(Reporter: patrick.hendriks+bugzilla, Unassigned)

References

(
URL
)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+)
Gecko/20020318
BuildID:    2002031803

1) the new download manager has no PAUSE button, only a CANCEL button.
1a) the new download window has no RESUME button

imho adding these buttons will make it a real download MANAGER, instead of only
a download VIEWER

perhaps then downloads can be resumed in a next session as well.

I love the potential of it though!

Reproducible: Always
Steps to Reproduce:
1.d/l something
2.open d/l manager
3.try pressing pause/resume
   or 
try resuming a d/l in a next session (after closing browser/reboot)

Actual Results:  none

Expected Results:  pause resume button in d/l MANAGER
To Blake
Assignee: law → blaker
Heh.

Blake, if you don't want to hack in the resume support I did, you should at
least support Pause/Resume for same-session support.

-> dl manager

Err, actually, this was filed on an http url, which isn't suported for cross
session support yet. I think you can still do same-session stuff via
Pause/Resume, but I'm not sure.
Status: UNCONFIRMED → NEW
Component: File Handling → Download Manager
Ever confirmed: true
*** Bug 132167 has been marked as a duplicate of this bug. ***
*** Bug 132114 has been marked as a duplicate of this bug. ***
Depends on: 129921
Keywords: nsbeta1
OS: Windows XP → All
Hardware: PC → All
nsbeta1-, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla1.2alpha
adding self to cc list
*** Bug 136843 has been marked as a duplicate of this bug. ***
this bug should be fixed quickly!!!
CC myself, I also think this is a very important feature, being able to pause
some downloads in a session, and being able to resume downloads in next session
if you cant resume after a pause, then its a chancel and no pause button.
if you want to add resume, then this is an enhancement :P
interesting feature after all
*** Bug 159086 has been marked as a duplicate of this bug. ***
I'd like to point out that a Download "Manager" that doesn't allow you to manage
your download is quite pointless. AFAIK, managing a download usually means to be
able to stop, pause and resume it, even across sessions...

Look at the marvelous GNU wget.

I guess I'll just keep using wget from the command line for the time being.

BTW, I've also disabled the DM window from appearing, since it gives me no
information at all: I get more from the regular download window, i.e. the
download percentage, even when minimized, and has a pause button.

Adding myself to CC:
QA Contact: sairuh → petersen
I dont understand why this is not fixed, it must be rather easy for those
initiated in the code. If you are downloading a certain file and the line breaks
or you just exit mozilla you can resume the download by going to the URL where
you started the download and click the file again. The download starts where it
was broken.

Now, how hard is it to add a "Resume" button, which really do nothing but in
background opens the file's URL again. (it must also NOT open the dialog that
asks you for the filename).

It sounds easy. (not for me since I would have to browse the code a while to
find out where to place the functionality but for those already initiated...).

The Pause could then be just a break that connection.
Arne, you have no idea about this stuff, you even said so. so PLEASE SHUT UP.
if it is easy for you, sure, go on implement it.
if not, please don't tell others how easy you think it is.
in addition, such comments just piss developers off. thanks for listening.
resuming by downloading/clicking on the file again just works if you know where
you downloaded the file to. as not even in the current version 1.3b (tested it
on winXP) the properties for the downloading files is showing up anymore, it's
totally unusable, because it makes the getting of large files (such as
linux-isos or stuff like that) impossible, if your line is unstable.

please fix as fast as possible.

regards,
parasew
Target milestone missed
If the connection fails, or your computer hangs or something, the download is
placed at a "cancelled" mode. Who sets this flag ? What if it was set to paused
instead, then you could just doubleclick and press resume ?

Could someone explain what the problem with the solution of this bug is really ?
Arne:
Would you please implement support for pause/resume (across sessions, of course)
in the backend code (necko)? We would really love you for that.

If you can't write up the code for it, then please just shut up until that's done.
There is backend support, at least for FTP. Its just not hooked up to anything.

There isn't support for http, but the interface was designed so that it was
protocol independant. See nsIResumableChannel.
bbaetz:
Who would do this hookup then?
And who would o the work for HTTP?

If we have a component called "download manager", it also should be useable as
such (or at least have some basic functionality of one)
Robert Kaiser, what is your real problem ? Why Do you tell me what to say ?

I might implement this, but I need info so I ask questions.

I was referring to the fact that you can pause a download (in a session) and
resume it, I assumed that resume would start it at least from the beginning,
even at the next session. 

*IF* that is true , explain to me why if a connection break or a closing of
mozilla, the file download can not be set to paused and resumed when the
connection gets back, or the computer is restarted.

else
explan to me why the URL can not easily be seaved for next session ?)

I am talking about resuming from beginning, not from where the download was stopped.
I am talking about resuming from beginning, not from where the download was stopped.

Starting from the beginning sounds like a RESTART button.

This bug is about implementing PAUSE and RESUME isn't it?
Being able to restart (not resume) a download that has stopped because of system
crash or connection failure is a first step IMO. It can also be of used when you
cannot wait until it is finished this session but want a convenient way to
restart the download in another session, without having to find the page where
you started the download.

Additionally, there seams to be cross-session resuming, the only thing missing
is the user interface, or how do you explain this:

I click the "Latest Builds", choose the windows version of mozilla, let the
download run until 1200kb, doubleclick on the file in download manager, PAUSE it
in the dialog that shows, DONT PRESS CANCEL, but close the dialog. reboot the
computer and go to "Latest Builds" and choose the same file. The download starts
at 1200kb...

So, I find it to be "just" the user interface that need the extra pause and
resume (perhaps restart?) buttons in the download manager, AND the saving of the
URL for each entry in the file manager (in case someone someday presses PAUSE,
reboots their computer and press RESUME)...

If there is something I have missed, Please tell me what it is, dont tell me to
implement it, I might implement it, but I need to know if I have missed
something, if so WHAT,  or is an URL save and two extra buttons in the download
manager all it takes ?


I have looked at some of the code relavent to this bug because I'm interested in
implementing pause/resume in my phoenix extension (download statusbar).  The
mozilla download-manager, the phoenix download sidebar and my extension all work
in similar ways so anything that fixed this bug would add pause/resume to all
three (other than UI).  I'm primarily concerned with in-session pause/resume; 
it seems there are other bugs for cross session and crash resuming, although a
good fix for one might fix them all (bugs 18004 and 131871).

Here is what I can see from the code:
    It appears that each download has a corresponding nsIRequest.  The progress
dialog boxes are able to pause and resume the download by calling suspend() or
resume() on this nsIRequest.  The dialog boxes get the reference for the
nsIRequest from the nsIWebProgressListener messages, but the trouble is, the
download manager doesn't use the nsIWebProgressListener.  
    To get the reference to the nsIRequest, the download manager could either do
the same thing that the progress dialogs do: implement the
nsIWebProgressListener and strip off the nsIRequest, or it would be nice if
there were a getRequest function.  The name attribute of the nsIRequest is the
url of the file, so it would be simple to look up the nsIRequest by this name.
If you can get the reference to this request the rest should be easy.  

I wish I knew if any of the mozilla heavyweights already had an idea of how they
wanted to make this work.
The cause seems very simple.  If you start a second download with the same
filename, regardless of the server name/location/destination, the DM lists the
second and successive downloads in the same entry.  If you watch, you will see
the other download(s) briefly appear, with the "source" column unchanging, but
the progress, time left, speed, and transferred columns changing to show the
other download(s).  This change lasts half a second every eight seconds with two
downloads.
When an entry like this is selected, the only buttons available are Cancel and
Properties, and the properties window only has Cancel and Pause.  Even after all
downloads under the same name have finished, the buttons do not change.  Since
the "Remove from list" button is not available, it cannot be removed either.
This is in Moz 1.5b on W2K SP2.  I have never looked at the Moz code before, but
I will attempt to find the offending code (wish me luck ;).
CCing myself. I've been missing this feature for a while.
Product: Browser → Seamonkey
*** Bug 196901 has been marked as a duplicate of this bug. ***
Assignee: bross2 → download-manager
QA Contact: chrispetersen
Fixed by the new download manager UI introduced in bug 472001 for SeaMonkey 2.0 Beta 1 and later.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.