Downloading continues after clicking Cancel or close window button in download dialog

VERIFIED FIXED in Camino0.7

Status

VERIFIED FIXED
16 years ago
16 years ago

People

(Reporter: winnie, Assigned: sdagley)

Tracking

unspecified
Camino0.7
PowerPC
Mac OS X

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
07-24 build on OS 10.1.5

Found this bug while verifying 145800.

1.  Download a file, e.g. from ftp://ftp.mozilla.org/pub/chimera/nightly/latest
2.  Single click to download the file.
3.  Download dialog comes up.  Select where the file is to be downloaded to.
4.  Download begins.
5.  Click the Cancel button (or the red close window button) in the download dialog.
6.  Download dialog disappears.

Expected result:  Download stops.
Actual result:  Download continues and finishes.  The downloaded file appears
where I had specified it to go in step 3.
(Reporter)

Comment 1

16 years ago
This behavior does not happen when right-clicking to download a file.
Summary: Downloading continues after clicking Cancel or close window button in download dialog → Downloading continues after clicking Cancel or close window button in download dialog

Comment 2

16 years ago
Using FizzillaCFM/2002072203, I never even saw a download progress dialog; the
download simply happened in the background.

Updated

16 years ago
Status: NEW → ASSIGNED
Blocks: 129923
Depends on: 55690
i'm wondering if this might be affected by the annoying "start predownloading
before the user selects target location" feature. see bug 55690 (and bug 129923)
for the gorey details.
(Assignee)

Comment 4

16 years ago
taking.  I was in the urloader code recently so I'll see what's happening here
Assignee: sfraser → sdagley
Status: ASSIGNED → NEW
(Assignee)

Updated

16 years ago
Target Milestone: --- → Chimera0.5
(Reporter)

Updated

16 years ago
No longer blocks: 129923
Target Milestone: Chimera0.5 → Chimera0.6
(Assignee)

Updated

16 years ago
Target Milestone: Chimera0.6 → Chimera0.7
(Assignee)

Comment 5

16 years ago
I can't duplicate this problem ina  debug build.  anybody seen it recently in a
production build?
(Assignee)

Comment 6

16 years ago
Here's the problem:

NS_IMETHODIMP
nsDownloadListener::SetObserver(nsIObserver * aObserver)
{
  return NS_ERROR_NOT_IMPLEMENTED;
}

the uriloader code is never being notified when the Cancel button is hit in the
download progress dialog.
(Assignee)

Comment 7

16 years ago
*** Bug 181417 has been marked as a duplicate of this bug. ***
Component: General → Downloading
QA Contact: winnie → petersen
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 8

16 years ago
Created attachment 108235 [details] [diff] [review]
Implement nsDownloadListener::SetObserver

nsDownloadListener::SetObserver is needed so uriloader is notified when a
download is canceled otherwise it'll attempt to post-process the partially
downloaded file rather than deleting it
(Assignee)

Comment 9

16 years ago
Comment on attachment 108235 [details] [diff] [review]
Implement nsDownloadListener::SetObserver

asking ccarlen for his review since code was lifted from UDownload
Attachment #108235 - Flags: review?(ccarlen)

Comment 10

16 years ago
Nuke the " - se sez ccarlen.". otherwise it looks OK.
Comment on attachment 108235 [details] [diff] [review]
Implement nsDownloadListener::SetObserver

>? Chimera.pbproj/sdagley.pbxuser
>Index: src/download/nsDownloadListener.h
>===================================================================
> 
>+    // These two are mutually exclusive - se sez ccarlen.

Don't do it just because I said so in the context of PPEmbed ;-) (get rid of
it)

>Index: src/download/nsDownloadListener.mm
>===================================================================
> NS_IMETHODIMP
> nsDownloadListener::SetObserver(nsIObserver * aObserver)
> {
>-  return NS_ERROR_NOT_IMPLEMENTED;
>+  if (aObserver)
>+    aObserver->QueryInterface(NS_GET_IID(nsIHelperAppLauncher), getter_AddRefs(mHelperAppLauncher));

    Shorten to:
    mHelperAppLauncher = do_QueryInterface(aObserver);
>+  return NS_OK;
> }
> 

Otherwise, good.
Attachment #108235 - Flags: review?(ccarlen) → review+
(Assignee)

Comment 12

16 years ago
Checked in
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 13

16 years ago
Verified in the 2002-12-05-04 NB under 10.2.2
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.