191977 - Downloading: File not saved if progress dialog is the last open window

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect)

Description

[Erik]

Environment:
==============
OS: Win NT 4.0 SP-6
Phoenix: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20030127
Phoenix/0.5


Summary:
=========
If one downloads a file to harddisk and one closes all browser windows while the
download is still in progress and the checkbox " " is unchecked, the downloaded
file is not saved to the desired location.

Several previous phoenix bugs have been marked duplicate of Mozilla bug #181374,
but since this bug has been fixed the problem in phoenix still persists.

Note: 
- I filed a new bug as the steps may be vary from the previously filed bugs
(e.g. I need to uncheck 'keep the window open' in the progress dialog).

- this bug is at least major severity because of data loss

Reproducible: always


Steps to Reproduce:
====================

1. start phoenix
2. goto http://www.orionstudios.com/direct/DirectDVD.exe 
3. in the dialog {Opening DirectDVD.exe} dialog select 'Save to disk'
4. click [Ok]
5. in screen {Enter name of file to save to...} choose an easy to search directory
6. click [Save]
7. progress dialog {xxx% of DirectDVD.exe saved} appears
8. UNCHECK!!! the checkbox 'Keep this window open after the download is complete'
9. While download proceeds close all open browser windows


Actual Results:  
================
The download completes, the progress dialog closes and the harddisk is doing
some stuff, but the file is not saved to the previously specified directory!


Expected Results:  
==================
Progress dialog closes and downloaded file is saved to the specified directory!


Additional Information:
========================
If one selects the checkbox 'Keep this window open after the download is
complete' the file is saved correctly to the specified location.

Comment 1

[Erik]

Checked additionally with latest nightly build of Mozilla ( Mozilla/5.0
(Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030204 ) to see, whether the
original Mozilla has not been fixed, but with Mozilla everything works fine.

Comment 2

[Erik]

Wrong UA string in bug-report - the correct one should look like the following:

Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20030204
Phoenix/0.5

Comment 3

[Erik]

According to a related thread in mozillazine
(http://www.mozillazine.org/forums/viewtopic.php?p=41421) this bug ocurs also
with Windows XP --> OS = All

Comment 4

[David P James]

WFM Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030202 Phoenix/0.5

I get the expected results (I watched it moved the file out of the /tmp dir when
as it closed down the downloads window) so it is likely to be a Windows-only bug
now.

-->OS to Windows XP from All (XP because it seems to affect all Windows builds,
so use the most recent)

Sébastien, can you confirm this bug?

Comment 5

[Sébastien Delahaye]

Yup, confirming. It looks like bug 181374, which is supposed to be fixed, at
least for moz. All dupes of bug 181374 were Windows only too.

The patch for bug 181374 refers to
xpfe/components/download-manager/src/nsDownloadManager.cpp, and I'm not sure,
but I think Phoenix uses a fork of the download manager.

Comment 6

[Erik]

Yeap - I checked the fix for bug #181374 for Mozilla and there this bug has
really been fixed (see comment #1) - so it just doesn't work in Phoenix...

Comment 7

[Sébastien Delahaye]

*** Bug 192463 has been marked as a duplicate of this bug. ***

Comment 8

[David Tenser [:djst]]

I'm setting the target milestone to 0.6. If the developers disagree, please
remove it again.

Comment 9

[noririty]

I agree with comment #12.

The patch only landed to:
/xpfe/components/download-manager/src/nsDownloadManager.cpp
But it seems to be need of land also:
/browser/components/downloads/src/nsDownloadManager.cpp

Comment 10

[Sébastien Delahaye]

*** Bug 202397 has been marked as a duplicate of this bug. ***

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

I've checked in the gist of bz's patch from 181374. The files are still diverged
a bit, I'll be looking at resyncing dlmgr files between seamonkey and firebird
during 0.7

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

oops

Comment 13

[Ben Goodger (use ben at mozilla dot org for email)]

-> me

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

.

Comment 15

[noririty]

http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/components/downloads/src&command=DIFF_FRAMESET&file=nsDownloadManager.cpp&rev1=1.27&rev2=1.28&root=/cvsroot
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/browser/components/downloads/src&command=DIFF_FRAMESET&file=nsDownloadManager.cpp&rev1=1.28&rev2=1.29&root=/cvsroot