66323 - We should always show the progress dialog even if we are done with the download

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Scott MacGregor]

This came out of discussion in the meta bug complaining about why we salt the
file names of the temp files used by the external handler.

Currently when you click on a link containing content that needs to be saved to
disk or opened using an external application, we begin downloading right away
while we show you the open / save to disk dialog. When you dismiss that dialog,
if we haven't finished downloading the content already, we then bring up a
progress dialog so you can track the remainder of the download.

Several folks have told me they found it confusing that they never saw a
progress dialog in the case where we finished the download b4 the user dimissed
the open/save dialog so we are already done.

this bug is to describe a new behavior where we bring up the progress dialog,
show it at 100% then bring it down and open the desired application.

it will make small downloads seem a little longer 'cause we'll be bringing up
this progress dialog just to show you we are done but it will make things less
confusing possibly.

Comment 1

[Scott MacGregor]

triaging.

I have a fix for this in my tree.

Comment 2

[Scott MacGregor]

Attachment: proposed fix. Also includes fix for #61947

Comment 3

[sairuh (rarely reading bugmail)]

some shuffling...

Comment 4

[(not reading, please use [e-mail] instead)]

sorry for the delay.

r=sspitzer

Comment 5

[Scott MacGregor]

I just checked in the fix for this. To see this, click on a link that requires
the external handler. Before dismissing the Open/Sve To Disk dialog wait long
enough so you think the download is done. Now save it to disk. 

You should see the progress dialog come up for a few seconds at 100% with the
Elasped Time and Remaining time fields filled in. 

Try the same thing with open. The only weird thing here is that we spawn the app
before the dialog actually shows itself. I have to fix that part. 

Try the same thing with downloads that are still happening after you dimiss the
open/save dialog just to verify that they are still working correctly too =).

Comment 6

[sairuh (rarely reading bugmail)]

tested using 2001.02.09.08 comm bits on linux, winNT and Mac. i used Acrobat
Reader as the external app to handle pdf files. mscott, lemme know if the
results for Test B [and, consequently, Test C] are expected --if they are, i'll
go ahead and vrfy this. thx!

Test A
------
click pdf link, wait till download would be done, then select Save to Disk. then
select download dir in file picker, click OK.

result: after i selected the download location, the progress dialog appears very
briefly, then goes away... iirc, the checkbox for keeping the dialog up after
download complete is off. looks like expected behavior, since i checked the box
[for another, later download], and then the progress dialog persisted.

Test B
------
click pdf link, wait till download would be done, but keep radiobutton set to
Open.

result: external app launches, but the download progress dialog does appear with
the meter filled in completely [along the correct Time Left and Elapsed Time].
this dialog does go away if the persistence checkbox is off --but it *will*
remain if the checkbox is on. mscott, is that latter behavior expected, or a
bug?

Test C
------
like Test B, except that i hit the OK button while the download is in progress.

result: same results as Test B.

Comment 7

[sairuh (rarely reading bugmail)]

side note: on the mac i used Stuffit as the external handler [got one too many
crashes when using Acrobat, feh].

Comment 8

[Scott MacGregor]

hi sairuh, yup that's the intended behavior (what you saw in test case B with
the checkbox selected).

Comment 9

[sairuh (rarely reading bugmail)]

cool. vrfy'ing this puppy...

Comment 10

[Aleksey Nogin]

This patch created the nsExternalAppHandler::ExecuteDesiredAction function that
would return an uninitialized nsresult value when (mProgressWindowCreated &&
!mCanceled) is not true.

Comment 11

[Scott MacGregor]

I'm not sure why this bug is listed as open. We fixed this ages ago. 

Comment 12

[sairuh (rarely reading bugmail)]

yep, vrfy.