204548 - Download Location defaults to ~/Desktop Folder/ and shouldn't

Status: RESOLVED FIXED

(Camino Graveyard :: Downloading, defect)

Description

[Joe Chellman]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030423 Chimera/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.4b) Gecko/20030423 Chimera/0.7+

I have my downloads folder on a removable firewire drive.  When the drive isn't
mounted, Chimera downloads files to ~/Desktop Folder/, which isn't the correct
path on Mac OS X of course.

I think downloading to the desktop is a good idea, but it should be ~/Desktop.

Reproducible: Always

Steps to Reproduce:
1. Set the download location to something that can disappear (e.g. a removable
drive) in the System Preferences.
2. Unmount the drive.
3. Download some file, a stuffit archive or whatever.


Actual Results:  
The files are downloaded to ~/Desktop Folder/, which is created if it doesn't exist.

Expected Results:  
Download to ~/Desktop/

Comment 1

[Greg K.]

See also bug 179901.

Comment 2

[Steve Dagley]

As Greg noted this is the same bug as #179901 which was only fixed on the
Chimera branch.  Here's the diff for that checkin (since I didn't attach a patch
to that bug):
<http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpcom/io&command=DIFF_FRAMESET&file=nsDirectoryService.cpp&rev1=1.43.18.5.8.3&rev2=1.43.18.5.8.4&root=/cvsroot>

Comment 3

[Len Laughridge]

I initially reported this under bug 201291.  See that entry for my description.
 The comments under that bug regarding the settings from Internet Config are
accurate, but regardless, this should *not* occur at all. 

Comment 4

[Rolf Braun]

This bug is definitely not limited to camino. It is happening for us all the
time in netscape 7.1 (see bug 200289 comment 28) and latest mozilla browser
suite nightlies. See bug 201291.

The patch referenced does fix the issue (which is probably also a mac os x bug
in FindFolder). Is there a particular reason that patch hasn't been applied
outside the Chimera branch?

Comment 5

[Rolf Braun]

Hmm, I should be more specific. There are two separate problems affecting us.
One of them is fixed by the patch in comment 2 -- the default download folder
should be ~/Desktop and not ~/Desktop Folder.

The other problem is that the default is used when it shouldn't. Currently,
users have no ability to set the download directory in IC and have it work in
moz across multiple machines using the same preferences, which makes it hard to
fix the first problem without the patch, as well. I've described the situation
around that in bug 200289 comment 28.

Comment 6

[louis bennett]

see also bug 215863

Comment 7

[louis bennett]

see also: bug 200289

Comment 8

[Josh Aas]

taking

Comment 9

[Josh Aas]

Attachment: fix mac desktop folder macro

This should solve this bug, as well as 227117 and maybe 200289.

Comment 10

[Steve Dagley]

Josh, Unless nsDirectoryService has been depricated your fix won't fix the
problem.  Nor is hard coding a directory name a good idea (although I'm not sure
"Desktop" ever gets localized).  Please take a look at the fix I reference in
comment #2 and apply it to a current tree to see if it is still valid.

Comment 11

[Josh Aas]

Attachment: the real deal

Yup - here's the real deal. This is tested and it works great. Its just the
patch from comment 2 updated to work on the current trunk. The other patch
doesn't solve this problem, but its such a blatant error that maybe it is best
to check that in too. Its got to improve whatever situation that code is for.

Comment 12

[Steve Dagley]

Comment on attachment 138464 [details] [diff] [review]
the real deal

r=sdagley

Comment 13

[Steve Dagley]

Weird, I didn't change the superreview flag.  Time to bug Myk.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 138464 [details] [diff] [review]
the real deal

sr=bzbarsky

Comment 15

[Boris Zbarsky [:bzbarsky]]

I just checked this in to the 1.7a trunk.  If things are happy and quiet about
it in a few days, go ahead and ask for 1.6 approval (resolve the bug fixed first
and all that).

Comment 16

[Mike Pinkerton (not reading bugmail)]

thanks for taking care of this, guys.

Comment 17

[Brendan Eich [:brendan]]

Comment on attachment 138464 [details] [diff] [review]
the real deal

If as bz suggested this has been tested on the trunk, go for 1.6 branch checkin
-- do it soon (today or tomorrow), I'm not sure when 1.6 is wrapped up, but
it's very close to done.

/be

Comment 18

[Boris Zbarsky [:bzbarsky]]

Checking in xpcom/io/nsDirectoryService.cpp;
/cvsroot/mozilla/xpcom/io/nsDirectoryService.cpp,v  <--  nsDirectoryService.cpp
new revision: 1.66.12.1; previous revision: 1.66
done