270557 - downloads fail silently if the default download path is invalid, e.g. leads to a removed drive

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[Matthias Bohnen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.5) Gecko/20041108 Firefox/1.0

I removed a harddisk from my PC, (Drive E:), but i forgot to change the the
default download path in Firefox from "E:" to something else. Then, when I
downloaded something, Firefox would download all data (to a temporary file i
guess) but then the download would fail at 99%. Thats quiet annoying if you just
downloaded a few hundred megabyte. And removable drives like USB-Sticks get more
and more popular, so i guess more people will experience this prolem.

What I don't like about Firefox' behaviour: 
1. Firefox should give the user an error message explaining his problem with the
download. 
2. If the default download path is not existant, Firefox should save the
download to an default-default download path, e.g. "Desktop" AND tell the user
about the new download path.

Reproducible: Always
Steps to Reproduce:
1. Create a temporary drive on your PC, for example with an USB-Stick.
2. Start Firefox and change the default download path to that drive.
3. Remove the USB-Stick 
4. Start Firefox and try to download something. 

Actual Results:  
The download fails

Expected Results:  
The download should be saved somewhere else

Comment 1

[Parag Warudkar]

I can confirm this behaviour - There is no error message from Firefox if the
target drive/path does not exist / is invalid. There must be an error message -
or the user is left believing the download succeeded.

Comment 2

[OstGote!]

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

Comment 3

[Jay Sheth]

I can confirm this bug, as the same thing happened to me. For more info, please see 
http://www.moztips.com/index.php?id=435

Comment 4

[dante hicks]

first bugzilla bit, sorry if in wrong place:  i can confirm the error as well,
with an invalid path set as your download location firefox fails silently. 
should warn perhaps or force new target location to be set.  download manager
does not even pop up.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

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

Comment 6

[Asa Dotzler [:asa]]

->mconnor

Comment 7

[:Gavin Sharp [email: [e-mail]]]

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

Comment 8

[Son Le]

Attachment: save to desktop if download path is invalid

if default download path is invalid, save to the desktop instead.

Comment 9

[Joey Minta]

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

Comment 10

[Mike Connor [:mconnor]]

Comment on attachment 190936 [details] [diff] [review]
save to desktop if download path is invalid

this is the wrong fix.	If the previous block took case 0 and failed, you don't
fix the bug.

The right fix is to add an exists() check to the validateLeafName function, so
instead of:

if (!aLocalFile)
  return null;

you have

if (!aLocalFile || !aLocalFile.exists())
  return null;

which forces up the filepicker and lets the user pick something valid.

Comment 11

[Son Le]

Attachment: the right fix

I thought everyone has some kind of a 'desktop' folder as default.

Comment 12

[Mike Connor [:mconnor]]

Comment on attachment 191152 [details] [diff] [review]
the right fix

In theory, they do, but its possible for this to fail and we need to fall back
properly and consistently.

Comment 13

[:Gavin Sharp [email: [e-mail]]]

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

Comment 14

[Son Le]

If someone can check this in for me it would be terrific.

Comment 15

[:Gavin Sharp [email: [e-mail]]]

Checking in nsHelperAppDlg.js.in;
/cvsroot/mozilla/toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in,v  <-- 
nsHelperAppDlg.js.in
new revision: 1.32; previous revision: 1.31
done

Comment 16

[Reed Loden [:reed]]

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