Closed Bug 51018 Opened 25 years ago Closed 25 years ago

navigate while downloading kills download

Categories

(SeaMonkey :: UI Design, defect, P2)

All
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: bugzilla, Assigned: mscott)

References

()

Details

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

Attachments

(1 file)

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.
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
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
Blocks: 50326
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+]
Any progress?
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
if u insist.... :)
QA Contact: shrir → sairuh
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.
Keywords: pp
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...
Keywords: pp
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.
pdt agrees p2.
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp2]
Target Milestone: --- → M18
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
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
nsbeta3- then
Whiteboard: [nsbeta3+][pdtp2] fix in hand → [nsbeta3-][pdtp2] fix in hand
rtm+, this is high frequency.
Whiteboard: [nsbeta3-][pdtp2] fix in hand → [nsbeta3-][pdtp2][rtm+] fix in hand
mscott, when you get a chance, can you attach the rest of the fix and r= and sr= in order to get the rtm++?
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.
Whiteboard: [nsbeta3-][pdtp2][rtm+] fix in hand → [nsbeta3-][pdtp2][rtm++] fix in hand
PDT marking [rtm++]
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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Works for Me Platform: PC OS: Windows 98 Mozilla Version: 2000100508 Marking as Verified
Status: RESOLVED → VERIFIED
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...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
...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!
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → FIXED
Sorry It was in the trunk build...adding vbranch keyword.
Keywords: vbranch
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: vbranchvtrunk
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.
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: