navigate while downloading kills download



19 years ago
8 years ago


(Reporter: bugzilla, Assigned: mscott)



Windows 98

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta3-][pdtp2][rtm++] fix in hand, URL)


(1 attachment)



19 years ago
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 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 file.

Comment 1

19 years ago
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. :)
Severity: normal → critical
Keywords: 4xp, dataloss, nsbeta3

Comment 2

19 years ago
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.
Assignee: gagan → mscott
Component: Networking → XP Apps


19 years ago
Blocks: 50326

Comment 3

19 years ago
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 :-)
Priority: P3 → P2
Whiteboard: [nsbeta3+]

Comment 4

19 years ago
Any progress?

Comment 5

19 years ago
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. :)
QA Contact: tever → shrir

Comment 6

19 years ago
if u insist.... :)
QA Contact: shrir → sairuh

Comment 7

19 years ago
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 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.
Keywords: pp

Comment 8

19 years ago
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
Keywords: pp

Comment 9

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

Comment 10

19 years ago
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

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

19 years ago
pdt agrees p2.
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp2]
Target Milestone: --- → M18

Comment 12

19 years ago
pending code review tomorrow, I have a fix for this and for showing progress in
a stand alone window (44176)
Whiteboard: [nsbeta3+][pdtp2] → [nsbeta3+][pdtp2] fix in hand

Comment 13

19 years ago
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.
Keywords: rtm

Comment 14

19 years ago
nsbeta3- then
Whiteboard: [nsbeta3+][pdtp2] fix in hand → [nsbeta3-][pdtp2] fix in hand

Comment 15

19 years ago
rtm+, this is high frequency.
Whiteboard: [nsbeta3-][pdtp2] fix in hand → [nsbeta3-][pdtp2][rtm+] fix in hand

Comment 16

19 years ago
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

19 years ago

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.


19 years ago
Whiteboard: [nsbeta3-][pdtp2][rtm+] fix in hand → [nsbeta3-][pdtp2][rtm++] fix in hand

Comment 18

19 years ago
PDT marking [rtm++]

Comment 19

19 years ago
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.
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 20

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

Marking as Verified

Comment 21

19 years ago
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!)

Resolution: FIXED → ---

Comment 22

19 years ago

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!
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED

Comment 23

19 years ago
Sorry It was in the trunk build...adding vbranch
Keywords: vbranch

Comment 24

19 years ago
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.
Keywords: vbranch → vtrunk
Hardware: PC → All
this is Fixed on the trunk in win32, mac and linux builds 10/06  removing vtrunk
and setting bug status to Verified.
Keywords: vtrunk
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.