300856 - Cannot set default download directory to home

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect)

Description

[Jonathan Baron]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050710 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050710 Firefox/1.0+

The default download is set to Desktop, something many Linux users
don't use (and I didn't even know what it was for the first 5 years
of using Linux).  I cannot figure out how to set it to my home
directory, which is what it was only a few builds ago.  If, for
example, I go to Browse/Filesystem (in Edit/Preferences/Download),
and click on home, then it goes back to Desktop.  And if I enter
./ in the Create new directory option, it is not allowed.


Reproducible: Always




I did search for bugs.  There were several about setting Desktop
as the default rather than "Ask me every time."  This is a different
bug.  "Ask me every time" works, but I don't think I should have
to rely on it, nor should I have to cd to Desktop in order to
deal with what I just downloaded.

I was able to get the behavior I wanted by removing my Desktop
directory, which is OK for me, but it may not be OK for others.
I set the correct directory by going back to Filesystem/
and then choosing home and "opening" my home directory.

Comment 1

[John Levon]

BTW, this is a new bug - it used to be possible. It sniffs as a bad interaction
between the new GTK+ file dialog and firefox. It's *incredibly* annoying...

Comment 2

[John Levon]

is this perhaps due to bug 241245 ?

Comment 3

[Sterling Christensen]

I think it has nothing to do with the GTK dialog box, because the same happens
to me even if I set the default download folder using about:config instead of
the dialog box.

I tried setting it to "/home/username/blah" and creating a
"/home/username/blah/Desktop" folder to see what would happen, but it just saved
in "/home/username/blah" like it's supposed to.

It's only if I set it to "/home/username" or "~", that it downloads to
"/home/username/Desktop" instead.

Comment 4

[John Levon]

Yep, same here, well spotted.

Comment 5

[Sterling Christensen]

I found a temporary workaround for people who really want to save to their home
folder.

Use this command to create a symlink to your home folder:
ln -s ~ ~/symlinktomyhomefolder

Then just set Firefox to download to ~/symlinktomyhomefolder. This will
effectively circumvent Deer Park's weird "~" -> "~/Desktop" mapping.

Comment 6

[Jonathan Baron]

In Firefox 1.06, the problem no longer happens.  The original behavior
has been restored.  I'm not sure that we should call this fixed until
others confirm.  I also note that the original behavior was a bit of a
problem too.  Now the download preference folder says "Desktop" but
the file actually goes to my HOME directory.  It isn't clear what someone
would do who WANTED it it to go to Desktop, and this behavior may somehow
depend on my setup.

Comment 7

[Unknown W. Brackets]

(In reply to comment #6)
> In Firefox 1.06, the problem no longer happens.  The original behavior
> has been restored.  I'm not sure that we should call this fixed until
> others confirm.  I also note that the original behavior was a bit of a
> problem too.  Now the download preference folder says "Desktop" but
> the file actually goes to my HOME directory.  It isn't clear what someone
> would do who WANTED it it to go to Desktop, and this behavior may somehow
> depend on my setup.

I agree it's still buggy in either case... but I'm seeing this in Deer Park
(1.1) which is what the reporter seems to be using.

Firefox 1.0.6 is not after, but actually before (in development, not time), Deer
Park (which is the codename for Firefox 1.1 alpha.)

-[Unknown]

Comment 8

[Henryk Hecht]

I'm seeing this in 1.5 release, five months later.  This is certainly a regression against 1.0.x, so something changed.  I suspect this is an easy fix for someone who knows what he is doing.

Comment 9

[Sokraates]

Nearly same problem here with FF 1.5 final on Ubuntu breezy (using mozilla's tar.gz-builds). FF uses /Home/username/ as default DL-folder.

My real default DL-folder is /home/username/download. When I try to set FF to this folder fromthe menu it tells me, I should specify a filename (?).

Using about:config leads to /home/username/download being displayed as default DL-folder, but still /home/username being used.

Another new problem: after trying to set the DL-folder from the menu I can't open the dialog again until I restart FF. Also after saving ANYTHING (page through dialogs or picture through right-click), I can't save anything else until a restart.

Comment 10

[Henryk Hecht]

OK, I tracked down some of what is happening with this bug.  There are at least three prefs involved:
browser.download.dir
browser.download.downloadDir
browser.download.folderList

Whoever named the chronologically second of .dir and .downloadDir wasn't thinking very hard...anyway, the problem (at least for me) seems to be with the folderList pref.  If I try to set "save all files to this folder" to $HOME, the UI shows "Desktop", .dir and .downloadDir are both set to $HOME, folderList is unset, but files are saved to $HOME/Desktop.  If I set it to anything but $HOME, then the UI shows the correct directory, .dir and .downloadDir are as expected, and .folderList is 2.  So...

As a workaround, you can probably set .folderlist to 2 (I guess, who knows what that number means!), and set .downloadDir and .dir to $HOME manually (i.e. about:config, or maybe user.js).  This is slightly less unaesthetic than making a symlink to $HOME, but the download prefs dialog will be confusingly wrong.

There are up to four bugs here:

1) When the file chooser sends back $HOME to the prefs code, the code does not set .folderList.  In fact, it un-sets it.
2) The UI does not reflect reality when whatever pref it reads to populate the display field is set to $HOME.
3) The file-saving code (wherever that is) arguably does something inappropriate when .folderList is unset (ignoring .dir and .downloadDir).
4) Whatever the semantic difference is between .download.dir and .download.downloadDir, no one in the universe it going to be able to figure it out from the names.  Probably one of them should be refactored into the other, but I cannot say.

I believe only 1 and 2 above need to be fixed to remedy this bug.  3 I guess is irrelevant if .folderList stops getting unset, and 4 is *somebody's* cleanup issue.  Unfortunately, I have no idea where the prefs dialog code (or most other firefox code, really) lives, so it is unlikely I can fix this in a reasonable amount of time.  Given the above, however, someone who knows the code even a little should be able to find the problem very quickly; and there's a workaround for now, anyway.

Comment 11

[Jonathan Baron]

(In reply to comment #10)

Another workaround is to set the download preference "Ask me where to save
every file."  Then the home directory gets set as the last one and used
the next time by default.

On the meaning of browswer.download.folderList, see
http://kb.mozillazine.org/Firefox_:_FAQs_:_About:config_Entries
which implies that 2 is indeed the correct setting.

Comment 12

[Steve White]

I see this in Firefox 1.5, Ubuntu 5.10, Kubuntu.

In Windows, button in
ools-->Options-->Downloads

Comment 13

[Steve White]

I see this in Firefox 1.5, Ubuntu 5.10, Kubuntu.

Comment 14

[Nick Thomas [:nthomas] (UTC+12)]

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

Comment 15

[pascal]

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

Comment 16

[Wolfgang Rosenauer [:wolfiR]]

Attachment: patch

This patch makes it possible to switch to the $HOME directory as download location.

Comment 17

[Wolfgang Rosenauer [:wolfiR]]

I still see two cosmetical issues:

1. switching to $HOME should maybe display "Home" instead of the path?
2. if $HOME/Desktop is not available it will fallback to $HOME but still
   displays "Desktop" in the pref UI

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Shouldn't this copy of _getSpecialFolderKey match the one in toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in? Seems like it should be, and that would solve this bug in basically the same way.(In reply to comment #17)

> 1. switching to $HOME should maybe display "Home" instead of the path?

You mean if you choose $HOME in the filepicker?

> 2. if $HOME/Desktop is not available it will fallback to $HOME but still
>    displays "Desktop" in the pref UI

I don't think that's really a problem. That's what I intended, the logic being that if you ask for "Desktop" and your Desktop directory is really $HOME then we should still show that you chose "Desktop".

Comment 19

[Wolfgang Rosenauer [:wolfiR]]

(In reply to comment #18)
> Shouldn't this copy of _getSpecialFolderKey match the one in
> toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in? Seems like it should be,
> and that would solve this bug in basically the same way.(In reply to comment
> #17)

yes, I haven't checked that code before but it should be the same or should share the code in one place if possible? Mike?

> > 1. switching to $HOME should maybe display "Home" instead of the path?
> 
> You mean if you choose $HOME in the filepicker?

Yes, but this is only minor and $HOME doesn't have a special treatment at 
the moment (as Desktop or Downloads has).

> > 2. if $HOME/Desktop is not available it will fallback to $HOME but still
> >    displays "Desktop" in the pref UI
> 
> I don't think that's really a problem. That's what I intended, the logic being
> that if you ask for "Desktop" and your Desktop directory is really $HOME then
> we should still show that you chose "Desktop".

Yes, the fallback was intended, but not having a Desktop subdirectory doesn't mean that my $HOME is something like a "Desktop" directory. IMHO this will confuse users because: what is Desktop if there is only a windowmanager without any Desktop and no directory in $HOME? At least I'm not really confident about this ;-) (as non-desktop-environment-user)

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

(In reply to comment #19)
> Yes, the fallback was intended, but not having a Desktop subdirectory doesn't
> mean that my $HOME is something like a "Desktop" directory. IMHO this will
> confuse users because: what is Desktop if there is only a windowmanager without
> any Desktop and no directory in $HOME? At least I'm not really confident about
> this ;-) (as non-desktop-environment-user)

I'm not sure how else to handle the Desktop preference. Feel free to file a bug with some suggested alternative :-)

Comment 21

[Wolfgang Rosenauer [:wolfiR]]

Attachment: patch #2

Now it uses the same code everywhere (toolkit/browser/mail) in getSpecialFolderKey functions. Special treatment of Windows and MacOS Desktop directories is not needed anymore since Desktop exists in XPCOM for all of them.
For now I suggest to take this patch for trunk and 1.8.1 and if everything looks good take it for 1.8.0.2.

Comment 22

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

(In reply to comment #21)
> Created an attachment (id=209432) [edit]
> patch #2
> 
> Now it uses the same code everywhere (toolkit/browser/mail) in
> getSpecialFolderKey functions.

What about the getSpecialFolderKeys in nsHelperAppDlg.js.in and contentAreaUtils.js ? They seem to be different, so may not need the same treatment, I guess. This is such a mess :(.

Comment 23

[Mike Connor [:mconnor]]

the nsHelperAppDlg.js.in is a js component, so we're going to have two copies of the same function, but having more than two seems rather wasteful, what are the actual differences?  (in meetings all week, not sure what we want to do here)

Comment 24

[Wolfgang Rosenauer [:wolfiR]]

I think all getSpecialFolderKey should carry the same code.
With that patch all should have the same code while the duplication is really bad.
With the patch applied I see no difference anymore between those functions in

toolkit/content/contentAreaUtils.js
toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in
toolkit/mozapps/downloads/content/downloads.js
browser/components/preferences/downloads.js
mail/components/preferences/downloads.js

(at least on trunk)

So it seems some file in toolkit should export the function which have to be usable from the others.
I'm no JavaScript guy so I'm not sure how this can be simplified.

Comment 25

[Mike Connor [:mconnor]]

Comment on attachment 209432 [details] [diff] [review]
patch #2

the ifdefs are broken, you have the following:

#ifdef foo
#endif
#else
#endif

Though the preprocessor might actually work somehow, you should be able to use #elif

r=me with that fixed, and please file a followup bug to clean up all of the duplicate code here (might be problematic to fix this in the 1.8.1 timeframe)

Comment 26

[Wolfgang Rosenauer [:wolfiR]]

Attachment: fixed patch

urgs, somehow my cut'n'paste didn't work. Thanks for the heads up.
Could this be taken for 1.8.0.2?

Comment 27

[Wolfgang Rosenauer [:wolfiR]]

checked in on trunk anf filed bug 325460

Comment 28

[Wolfgang Rosenauer [:wolfiR]]

checked in to 1.8branch

Comment 29

[Daniel Veditz [:dveditz]]

Comment on attachment 210354 [details] [diff] [review]
fixed patch

>Index: browser/components/preferences/downloads.js
>===================================================================
>+    if (aFolderType == "Desktop")
>+      return "Desk";
...
> #ifdef XP_WIN
>-    return aFolderType == "Desktop" ? "DeskP" : "Pers";

For something that is supposedly a linux problem, changing the return value in windows seems suspicious (was "DeskP", now "Desk"). Same for Mac, was "UsrDsk", now "Desk".

Comment 30

[Wolfgang Rosenauer [:wolfiR]]

(In reply to comment #29)
> 
> For something that is supposedly a linux problem, changing the return value in
> windows seems suspicious (was "DeskP", now "Desk"). Same for Mac, was "UsrDsk",
> now "Desk".
> 

The description for that is in comment #21
I understand that there are some doubts to take this in 1.8.0.2 without much time to test. What do you suggest? I'm pretty sure that it works that way. And I don't want to take another approach for 1.8.0 branch as for 1.8 and trunk.

Comment 31

[Mike Connor [:mconnor]]

This is the right fix, which restores the behaviour implemented in bug 241245 (which would be thet old prefwindow code).  "Desk" is a cross-platform replacement for the home/pers/whatever mismash, and should be safe (we have the same function in nsHelperAppDlg.js and contentAreaUtils.js already)

Comment 32

[Adam Guthrie]

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

Comment 33

[Adam Guthrie]

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

Comment 34

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 210354 [details] [diff] [review]
fixed patch

Still wanted for 1.8.0x as it's a lowrisk fix that fixes an obvious, and annoying UI bug.  (I'm still getting bug reports on this).

Comment 35

[Daniel Veditz [:dveditz]]

Comment on attachment 210354 [details] [diff] [review]
fixed patch

approved for 1.8.0 branch, a=dveditz for drivers

Comment 36

[Wolfgang Rosenauer [:wolfiR]]

Checking in browser/components/preferences/downloads.js;
/cvsroot/mozilla/browser/components/preferences/Attic/downloads.js,v  <--  downloads.js
new revision: 1.6.10.1; previous revision: 1.6
done
Checking in mail/components/preferences/downloads.js;
/cvsroot/mozilla/mail/components/preferences/downloads.js,v  <--  downloads.js
new revision: 1.4.8.1; previous revision: 1.4
done
Checking in toolkit/mozapps/downloads/content/downloads.js;
/cvsroot/mozilla/toolkit/mozapps/downloads/content/downloads.js,v  <--  downloads.js
new revision: 1.47.2.4.4.2; previous revision: 1.47.2.4.4.1
done

Comment 37

[juan becerra [:juanb]]

Verified, you can set home as the default download directory on:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9pre) Gecko/20061128 Firefox/1.5.0.9pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1pre) Gecko/20061128 BonEcho/2.0.0.1pre