Closed
Bug 51018
Opened 25 years ago
Closed 25 years ago
navigate while downloading kills download
Categories
(SeaMonkey :: UI Design, defect, P2)
Tracking
(Not tracked)
VERIFIED
FIXED
M18
People
(Reporter: bugzilla, Assigned: mscott)
References
()
Details
(Keywords: dataloss, Whiteboard: [nsbeta3-][pdtp2][rtm++] fix in hand)
Attachments
(1 file)
6.25 KB,
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•25 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. :)
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
Comment 3•25 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•25 years ago
|
||
Any progress?
Reporter | ||
Comment 5•25 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
Reporter | ||
Comment 7•25 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 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
Reporter | ||
Comment 8•25 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
there...
Keywords: pp
Assignee | ||
Comment 9•25 years ago
|
||
Assignee | ||
Comment 10•25 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
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•25 years ago
|
||
pdt agrees p2.
Whiteboard: [nsbeta3+] → [nsbeta3+][pdtp2]
Target Milestone: --- → M18
Assignee | ||
Comment 12•25 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
Assignee | ||
Comment 13•25 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•25 years ago
|
||
nsbeta3- then
Whiteboard: [nsbeta3+][pdtp2] fix in hand → [nsbeta3-][pdtp2] fix in hand
Comment 15•25 years ago
|
||
rtm+, this is high frequency.
Whiteboard: [nsbeta3-][pdtp2] fix in hand → [nsbeta3-][pdtp2][rtm+] fix in hand
Comment 16•25 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++?
Assignee | ||
Comment 17•25 years ago
|
||
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.
Updated•25 years ago
|
Whiteboard: [nsbeta3-][pdtp2][rtm+] fix in hand → [nsbeta3-][pdtp2][rtm++] fix in hand
Comment 18•25 years ago
|
||
PDT marking [rtm++]
Assignee | ||
Comment 19•25 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.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Comment 20•25 years ago
|
||
Works for Me
Platform: PC
OS: Windows 98
Mozilla Version: 2000100508
Marking as Verified
Status: RESOLVED → VERIFIED
Reporter | ||
Comment 21•25 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!)
reopening...
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Reporter | ||
Comment 22•25 years ago
|
||
...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 ago → 25 years ago
Resolution: --- → FIXED
Comment 23•25 years ago
|
||
Sorry It was in the trunk build...adding vbranch
keyword.
Keywords: vbranch
Reporter | ||
Comment 24•25 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.
Comment 25•25 years ago
|
||
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
Updated•21 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•