78193 - UTCH should support pause & resume

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Doug Turner (:dougt)]

The download widget should support pause and resume.  This would allow a user to 
suspend a download for x amount of time.  Then, after this time, they should be 
able to resume the download without any loss of data if possible.  FTP supports 
this functionality.

Comment 1

[Alex Bishop]

I think this is a duplicate of bug 18004.

Comment 2

[Doug Turner (:dougt)]

Attachment: Adds pause and resume functionality to the download dialog.

Comment 3

[Doug Turner (:dougt)]

It is not a dup of 18004.  "Resuming stopped downloads" is a much broader set 
than explict pause and resume functionaly.  Bug 18004 implies persistance.  This 
bug does not address that.

Comment 4

[Darin Fisher]

r=darin

Comment 5

[Blake Ross]

"pausablity"?  Shouldn't that be "pausability" (or am I misunderstanding what 
it's intended to mean)?  Please get Ben or Matthew to approve the UI changes 
before checking in.

Comment 6

[Doug Turner (:dougt)]

Attachment: JPEG of dialog.

Comment 7

[Scott MacGregor]

hey doug, this sounds like a neat idea.

Question, how are we going to get this to work for many of the other protocols
besides ftp and http that use this dialog? some protocols don't support the
ability to "pause" and "resume" things. Imap, mailbox ring a bell for starters =).

Comment 8

[Bill Law]

Could we combine the pause/resume buttons (change text to "Resume" after "Pause"
is pushed)?  The dialog is getting pretty congested with all those buttons...

I'm with Blake on changing the "pausablity" to something else.  Maybe
"...PauseButton" (if we go to a single button).

Also, all the 'document.getElementById("pause")'s and
'document.getElementById("resume")'s could be changed to 'dialog.pause's and
'dialog.resume's.

Comment 9

[Doug Turner (:dougt)]

Right.

So basically, in the first notification that I get from the progress listener, I 
QI the request to something that I know supports resuming.  Right now, I will 
enable only for the FTP protocol (REST rfc 959).  If the QI is successful, I 
unhide the pause and resume buttons.

When HTTP byte range support comes along, I will QI for that channel and enable 
the buttons for HTTP.  

Protocols like IMAP don't have to do anything special.

Comment 10

[Doug Turner (:dougt)]

Bill, actually, I think that the "Launch" and "Reveal" buttons should be 
invisible until the file is actually downloaded.  These two buttons don't make 
any sense prior to the point the file is on disk.

Comment 11

[Doug Turner (:dougt)]

Attachment: Patch 2. With renaming suggestions

Comment 12

[Scott MacGregor]

me thinks we engineers shouldn't be designing UI =). Can you set up a discussion
with German to get his input on how he would like to see your Pause/Resume
buttons integrated into this dialog? 

Sorry if this has already happened, I'm still catching up on all my email.

Personally, I really like Bill's suggestion of having one button for
Pause/Resume which toggles depending on the state you are in. 

Comment 13

[sairuh (rarely reading bugmail)]

cc'ing german for his comments.

i agree with both bill and mscott re: having a single pause/resume button.

Comment 14

[Doug Turner (:dougt)]

sure.  I can do this.  lets see what else ben, german, have to say before I hack 
on this a more.

Comment 15

[timeless]

+        // right now, all that supports restarting downloads is ftp (rfc959)
perhaps
// only rfc959 resume support (ftp) is implemented. see bug XXXXX

A reminder that most media players (QT, WMP, Real,..) and most browsers have 
seperate play/pause / stop/reload buttons.

Comment 16

[Peter Lairo]

A download dialogue is not a media player :)

Comment 17

[timeless]

[score:-5, silly, don't read]. Oh really? hrm... /me goes back through notes.

QuickTime, RealPlayer, mplayer.exe, WMP, WinAmp they can all play streaming 
media (or non streaming media that they download first).

mplayer's window is slightly shorter and wider than ours, as were qt2/3's media 
player, real player2-5 [and perhaps 6/7/8 in non video modes].  Their features 
are rather similar, filename/serverpath, timeelapsed/remaining, size, 
bit/transfer rate, play, pause, stop.  [... what do you call a window that lets 
you download and play music? perhaps a media player, but would it be unfair to 
say it downloads stuff?]

But there's one important difference, their window _is_ the application window, 
so they need to get the layout right. [actually, did qt4/5 use play and stop as 
one button? i don't remember]

I seem to recall blake and others rejecting the stop/reload combo button, but 
you didn't complain that i tried to draw a parallel to it. any reason?

Comment 18

[gabriel]

Wouldn't a better option be, as I have asked for elsewhere, to have two 
buttons 'Cancel and delete' and 'Cancel and leave file'. In conjunction with 
the ability to resume partially downloaded files, this would do pretty much 
what was asked for here.

Comment 19

[Blake Ross]

I think one of the reasons the stop/reload was rejected was because the button 
can be both triggered by the user and enabled/disabled/changed arbitrarily by 
the program, so there was a good chance that the user could click it at the 
wrong time, etc.  This isn't the case with this button, since the program won't 
really be updating the button on its own.  I, too, was going to suggest 
making them one button, however I'm not completely sure all users will 
understand that a download's paused if they don't see a disabled Pause button.  
Then again, since they had to click Pause to get it to say Resume, it shouldn't 
be hard to figure out.

Comment 20

[Doug Turner (:dougt)]

I say worse is better; lets check this patch in as is.  We still have 4 weeks 
until the next milestone.  In that time, all the UI hackers can debate if how to 
present this to the user.  In the mean time, the ftp backend can gets some 
cycles.

Comment 21

[timeless]

actually, in theory, the button should change for code reasons.

Doug: if the ftp connection drops, does the ui update?

i'm not opposed to checkin in now, but blake's view seemed to be ~worse is 
better is unnacceptable~.

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

I don't see the merit in having two buttons, other than adding clutter to this 
dialog. 

Comment 23

[Doug Turner (:dougt)]

ben, is that your only complaint?  if that changes, do I have a sr=ben?

Comment 24

[Ben Goodger (use ben at mozilla dot org for email)]

sure, ok, if you also fix the pausablity thing, sr=ben ;)

Comment 25

[Asa Dotzler [:asa]]

I think it would be nice to test this feature as soon as possible and early in
the Milestone cycle if possible.  Ben has OK'd the UI (at least as a temporary
front end for testing purposes) so go ahead and check this in.  Interested
people should draft a spec and file bugs on dougt if the current UI doesn't
match that spec.

Comment 26

[Doug Turner (:dougt)]

okay.  fixed checked in.  interested parties please take a look at it in 
tomorrow's build.

Comment 27

[sairuh (rarely reading bugmail)]

it's there now and works after a few quick tests. vrfy the three main platforms
using 2001.05.02.xx bits.

Comment 28

[Stefan Seifert]

okay a bit late in the discussion but anyway...

Nice comparison with media players and nice arguments...but why the hell doesn't
anyone compare this with a download manger? I think this would be a better
comparison.

And right away GetRight for example has a combined pause/resume button and I
like this cause you only need one of these at a time. And for example if you
click on pause in Winamp when its paused it resumes playing if you like your
media player comparison...

Comment 29

[Daniel Borgmann]

Yes and think of cassette recorders. They have one button for pause and resume.

Comment 30

[Alex Bishop]

We're drifting a bit off-topic here, but here goes anyway.

The interface for most media players is based on that for stereos. Stereos have
seperate buttons for functions that are mutually exclusive (for example, there's
still a play button when you're already playing and still a stop button when
you're stopped) because it's hard to dynamically change the labels of real life
buttons. Media players just copy the buttons of stereos (because everyone can
use a stereo).

One of the exceptions (in both stereos and their virtual equivilants) is the
pause button, which are usually acts a toggle. I guess this is because it's like
a mode that you can enable or disable (it doesn't actually stop playback like
play, just suspends it).

In terms of the interface for Mozilla's download dialogue, I think having a
combined pause/resume button would be best. It would cut down on visual clutter
and the user doesn't have to work out which button to press to reverse the pausing.

Blake Ross said "...I'm not completely sure all users will understand that a
download's paused if they don't see a disabled Pause button." I think it's only
really novice users that will be confused about that. And really novice users
probably won't be using Mozilla/Netscape. They'll be using IE because it's
nicely built in and they don't have to download another program (which, of
course, is why IE has such a huge market share). Anyway, if there were two
seperate buttons, Pause would be 'greyed out' when paused and 'lit up' when not
paused, which could confuse really novice users - remember they probably won't
understand the concept of disabled buttons (in fact, they may try to press pause
when it's disabled to resume their download).

I think we should just be glad that we've got something and let the UI people
sort out the UI. MPT, we're ready and waiting! :-)

Comment 31

[Matthew T (active 1999-2002)]

The current home for fixing up the UI is bug 67216.