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

RESOLVED FIXED

Status

Camino Graveyard
Downloading
RESOLVED FIXED
15 years ago
14 years ago

People

(Reporter: Joe Chellman, Assigned: Josh Aas)

Tracking

({fixed1.6})

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

15 years ago
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

15 years ago
See also bug 179901.

Comment 2

15 years ago
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>

Assignee: sdagley → ccarlen

Updated

15 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

15 years ago
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

14 years ago
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

14 years ago
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

14 years ago
see also bug 215863

Comment 7

14 years ago
see also: bug 200289
(Assignee)

Comment 8

14 years ago
taking
Assignee: ccarlen → josha
(Assignee)

Comment 9

14 years ago
Created attachment 138458 [details] [diff] [review]
fix mac desktop folder macro

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

Updated

14 years ago
Attachment #138458 - Flags: superreview+
Attachment #138458 - Flags: review+
(Assignee)

Updated

14 years ago
Attachment #138458 - Flags: superreview?
Attachment #138458 - Flags: superreview+
Attachment #138458 - Flags: review?
Attachment #138458 - Flags: review+
Attachment #138458 - Flags: approval1.6?

Comment 10

14 years ago
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.
(Assignee)

Updated

14 years ago
Attachment #138458 - Flags: superreview?
Attachment #138458 - Flags: review?
Attachment #138458 - Flags: approval1.6?
(Assignee)

Comment 11

14 years ago
Created attachment 138464 [details] [diff] [review]
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.
(Assignee)

Updated

14 years ago
Attachment #138464 - Flags: superreview?
Attachment #138464 - Flags: review?

Comment 12

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

r=sdagley
Attachment #138464 - Flags: review? → review+

Comment 13

14 years ago
Weird, I didn't change the superreview flag.  Time to bug Myk.
(Assignee)

Updated

14 years ago
Attachment #138464 - Flags: superreview? → superreview?(bz-vacation)
Comment on attachment 138464 [details] [diff] [review]
the real deal

sr=bzbarsky
Attachment #138464 - Flags: superreview?(bz-vacation) → superreview+
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).
thanks for taking care of this, guys.
(Assignee)

Updated

14 years ago
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
(Assignee)

Updated

14 years ago
Attachment #138464 - Flags: approval1.6?
(Assignee)

Updated

14 years ago
Attachment #138458 - Attachment is obsolete: true
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
Attachment #138464 - Flags: approval1.6? → approval1.6+
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
Keywords: fixed1.6
You need to log in before you can comment on or make changes to this bug.