51018 - navigate while downloading kills download

Status: VERIFIED FIXED

Description

[sairuh (rarely reading bugmail)]

couldn't find a bug like this querying browser-general, xp apps or networking 
--but do dup if it already exists. essentially, if i click on link to another 
page while i'm downloading a file, that download is aborted and file isn't 
completely saved.

does anyone see this on Mac or linux? (i don't have access to 'em right now.)

to repro:

1. go to the above url, and click on any of the download links from the build 
statusbar (near the top of the page. i selected the one for Windows (goes to a 
nightly mozilla-win32.zip build via ftp).

2. the downloading dialog appears. select Save on Disk and click OK.

3. the native File Save dialog appears. select a download location --i selected 
the desktop.

4. the download progress dialog appears. while this is up, click on a link to 
surf to another webpage, eg, "Netscape 6 Themes Contest Underway".

expected result: navigate to selected webpage, the download progress dialog 
stays up till complete, and the file is successfully downloaded.

actual result: navigate to selected webpage, *but*:

a. the download progress dialog suddenly goes away, and,

b. the download is aborted. on win98, no file appeared on the desktop. i also 
checked c:\windows\temp\ and the filesize of the file there was a lot smaller 
than expected. ie, incomplete, less than 2M --too small for the 8+ meg 
mozilla-win32.zip file.

Comment 1

[sairuh (rarely reading bugmail)]

bumping up sev. users should be able to surf while downloading. or, rather, 
downloading shouldn't be so fragile when a user attempts to surf. :)

Comment 2

[Bill Law]

I think this happens because we're downloading in the context of the browser 
window that initiates it.  If that browser surfs to another page, then it's the 
same as if you hit Stop and click on another link (or type in a URL).

This isn't Gagan's.  I'm going to reassign it to mscott.  He and I will have to 
figure out how to deal with this.

Comment 3

[selmer (gone)]

nsbeta3+, P2.  I don't think this would rate a P1, the dataloss is generally not
permanent - just click on the link again.  (I'm sure you can create scenarios
where the dataloss is permanent, that's why I moved it up to P2 from P3 :-)

Comment 4

[selmer (gone)]

Any progress?

Comment 5

[sairuh (rarely reading bugmail)]

still happens on win98 using mozilla 2000.09.19.09.

shrir/tever/asa --do any of you see this on linux or mac mozilla (or
commercial)? also, shrir, i'll take this off of your hands if you don't want it. :)

Comment 6

[shrirang khanzode]

if u insist.... :)

Comment 7

[sairuh (rarely reading bugmail)]

not a problem on linux mozilla or comm.

looks like it affects win32, since it run into this today using the comm bits
2000.09.20.05 on winNT. adding pp. to repro on winNT without incurring the wrath
of bug 53123:

1. go to http://www.mozilla.org and scroll down to the Nightly Build section.
2. click on the link for Macintosh.
3. select Save to disk.
4. select download location in the native dialog that appears. click OK.
5. surf to another web page while it's downloading.

result: downloading interrupted.

Comment 8

[sairuh (rarely reading bugmail)]

i take back the pp designation --i'm able to reproduce this on Mac OS 9.0
2000.09.20.08 opt comm bits. waiting for the mozilla mac blob to deflate to test
there...

Comment 9

[Scott MacGregor]

Created attachment 15164 [details] [diff] [review]
first half of fix....

Comment 10

[Scott MacGregor]

This patch contains the load group manipulation changes to make sure the helper
app content runs in a separate load group from the underlying browser window.
This means that browsing pages in that browser window doesn't interrupt the
download.

The down side is, because we aren't running in the browser context, hitting stop
in the browser doesn't stop the download. We need the progress dialog covered in
Bug #44176 for that.

I won't be checking in this patch until I finish the progress dialog.

Comment 11

[selmer (gone)]

pdt agrees p2.

Comment 12

[Scott MacGregor]

pending code review tomorrow, I have a fix for this and for showing progress in
a stand alone window (44176)

Comment 13

[Scott MacGregor]

selmer and i decided to hold off on this fix until rtm since we are so close to
getting the beta out the door. I didn't get it checked by the deadline of last
thursday at midnight.

Comment 14

[Phil Peterson]

nsbeta3- then

Comment 15

[selmer (gone)]

rtm+, this is high frequency.

Comment 16

[scottputterman]

mscott, when you get a chance, can you attach the rest of the fix and r= and sr=
in order to get the rtm++?

Comment 17

[Scott MacGregor]

sr=rpotts.

Just waiting for PDT to give me the plus so I can check it in. PDT: this fix is
also part of Bug #44176. So I'm really checking in the changes that are
contained within 44176 which also fix this.

Comment 18

[Phil Peterson]

PDT marking [rtm++]

Comment 19

[Scott MacGregor]

this is fixed on both the branch and the tip. Now, after you dismiss the helper
app dialog you'll see a stand alone progress dialog. You can browse to another
web page without a problem.

Clicking cancel on the download dialog cancels the helper app download.

Comment 20

[Keyser Sose]

Works for Me
Platform: PC
OS: Windows 98
Mozilla Version: 2000100508

Marking as Verified

Comment 21

[sairuh (rarely reading bugmail)]

hi Keyser, did you verify this with a trunk build or a branch build? (a branch
build comes from a directory ending with "MN6" and a trunk build comes from a
dir ending with "M18".) the reason i ask is that this bug (and any bugs fixed
after 21 Sept 2000) needs to be tested in both trunk and branch builds before
marking as Verified.

i know this is a confusing way to go about verifications --feel free to ask
people in #mozillazine for further clarification, if this still doesn't make
sense to you. (regardless, thanks a lot for your contribution and help!)

reopening...

Comment 22

[sairuh (rarely reading bugmail)]

...re-resolving...

pls put in the "vbranch" keyword if this still needs verification in the branch
--or, likewise, put "vtrunk" if this needs trunk build verification. thanks!

Comment 23

[Keyser Sose]

Sorry It was in the trunk build...adding vbranch
 keyword.

Comment 24

[sairuh (rarely reading bugmail)]

thx for checking this on win98, keyser! but since this occurred on mac as well
(i forgot to update the OS/platform, my bad), i'd like this to get
double-checked on trunk bits for the other platforms. :) the main reason here is
that this is a purty high profile bug...

asa, could you pls vrfy this using trunk bits on linux?

this looks fine when using 2000.10.06.xx-n6 [commercial branch] bits on linux,
mac and winNT. removing vbranch, and adding vtrunk so that this is checked on
mac and linux there.

Comment 25

[Asa Dotzler [:asa]]

this is Fixed on the trunk in win32, mac and linux builds 10/06  removing vtrunk
and setting bug status to Verified.