Closed Bug 241245 Opened 20 years ago Closed 19 years ago

Auto download to 'Desktop' downloads to home directory on Linux

Categories

(Toolkit :: Downloads API, defect)

x86
Linux
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla1.8final

People

(Reporter: glen, Assigned: bugs)

References

Details

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

I selected automatic downloads and chose the first option, "Desktop" as the
directory to place downloads into.  But when I download something, it gets
placed into my home directory instead.  I'm using Gnome on Fedora Core 1 if that
makes any difference.

Reproducible: Always
Steps to Reproduce:
1. Download something.
2.
3.
Actual Results:  
The download is placed in my home directory.

Expected Results:  
I expected the download to be placed on my desktop.
Confirming on today's nightly on FC1.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Automatically downloading to the Desktop doesn't work → Auto download to 'Desktop' downloads to home directory on Fedora Core 1
*** Bug 259025 has been marked as a duplicate of this bug. ***
*** Bug 259416 has been marked as a duplicate of this bug. ***
*** Bug 259510 has been marked as a duplicate of this bug. ***
Reporters, don't forget that not every Unix/Linux system has a desktop. But if
there's one (different from $HOME), it should be used. Where should we able to
get that information ?

Maybe this should be moved to the 'OS Integration' component ? I can't find any
other bug about it.
If it's not downloading to one's desktop though, it really needs not to say
"Desktop".  My Linux has no desktop, but even when the default directory is set
to my home directory, the preference dialog combo box for it reads "Desktop". 
This is not good.
Version: unspecified → 1.0 Branch
*** Bug 259511 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.0?
*** Bug 265505 has been marked as a duplicate of this bug. ***
Summary: Auto download to 'Desktop' downloads to home directory on Fedora Core 1 → Auto download to 'Desktop' downloads to home directory on Fedora Core
Summary: Auto download to 'Desktop' downloads to home directory on Fedora Core → Auto download to 'Desktop' downloads to home directory on Linux
It should download to the /home/<username>/Desktop directory.

If it doesn't exist, it should download to /home/<username>, and say to: "Home"
if i've set my default directory to say "c:\downloads\" and i'm currently
downloading to "d:\temp net files\", the next time i attempt to download
something, the default dialog box behaviour will remain at "d:\temp net files\".
during the download i had realized that all 8 files were on their way to
"d:\temp net files\" and none to "c:\downloads\" as displayed by the download
manager. this might be problematic if its a long download, and i forget that i
had set the file to download to a different folder than that displayed by the
download manager.

it's a slightly questionable design decision.

a small usability suggestion would be that the "All files downloaded to: [folder
name]" be replaced with a file specific sentence and link.

i.e. by default have the text read "File downloading/downloaded to: [folder name
as set by user in the options]" but if any downloads are active, it should be
specific to that download. clicking on "File1.zip" would display "Default
download folder: c:/downloads/" and clicking on "File2.mov" would instead
display "File downloading/downloaded to: c:/movie files/"

too much to ask for? redundant? what do you guys think?
forgot to add: this isn't a technical issue to much as it is a design issue.
and as such i dont think it is specific to linux.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041024 Firefox/1.0
Flags: blocking-aviary1.0? → blocking-aviary1.0-
The default path for downloaded files is "desktop" for any version (linux or
windows) but under linux the default path "desktop" doesn't exist : when you
click on it in the download window it doesn't open anything !
Might the default downloaded files path should be different between linux and
windows (and maybe mac too).
In linux /home/<username>/Desktop is the default path for desktop in most DE
(GNOME, KDE, XFCE etc. etc.) so simply default to that dir instead of
/home/<username>.

In the dropdown menu should be 3 options in total:
- Desktop (/home/<username>/Desktop)
- Downloads (/home/<username>/My Downloads)
- Home (/home/<username)
Please disable this idiotic feature as a default in Linux and change the dialog
for specifying a default location to no do it in a Windows(or Mac?) specific way!

There are so many ways how this could break:
*) in many but the simplest home installations, the home directories are in a
path that is different from /home/user - so in order to do this right you need
to find out the effective home directory location
*) nearly all Window managers allow the desktop directory to be changed, so in
order to do this you would need to figure out the currently active windowmanager
(because a user can switch between different ones) and use the window-manager
specific configuration file to figure out what the effective directory is.
*) Other window managers do not even have such a directory or the ability to
show files on the desktop
*) in some window managers it is possible to disable the feature of viewing
files on the desktop, even if the manager normally has this ability. Many Linux
users doe that because they hate this Windows-way of cramming your desktop with
all kinds of files 

In order to do this right on Linux, disable the default autoload feature and
provide a dialog that differes from the Windows dialog for specifying a default
location. This dialog could still show a selection of frequently used reasonable
default locations like ~/Desktop, ~ etc, but should not make assumptions that
will break in quite many cases. 
(In reply to comment #14)
> There are so many ways how this could break:
> *) in many but the simplest home installations, the home directories are in a
> path that is different from /home/user - so in order to do this right you need
> to find out the effective home directory location

$HOME environment variable

> *) nearly all Window managers allow the desktop directory to be changed, so in
> order to do this you would need to figure out the currently active windowmanager
> (because a user can switch between different ones) and use the window-manager
> specific configuration file to figure out what the effective directory is.
> *) Other window managers do not even have such a directory or the ability to
> show files on the desktop
> *) in some window managers it is possible to disable the feature of viewing
> files on the desktop, even if the manager normally has this ability. Many Linux
> users doe that because they hate this Windows-way of cramming your desktop with
> all kinds of files 

all this users could ever choose $HOME dir to download the files..

I think the best choice is:
Desktop ($HOME/Desktop) - default configuration (as is the default one on all
the major DE)
Home ($HOME) - available option for those who prefer this location

for all other special configurations you mentioned they could select:
A) Home
B) Other...
This patch is a first attempt to change the behaviour that "Desktop" is meant
as Home.
With this patch the default on Unix/Linux is that the $HOME is used as download

directory. It can be chosen in download preferences in addition to "Desktop"
and
"My Downloads".

The patch is not ready for checkin. I fear there are far too much ifdefs and
some dirty hacks, which could be solved better.
But maybe one of the mozilla folks can give some hints to improve the code for
inclusion in Firefox/Thunderbird.
Flags: blocking-aviary1.1?
Version: 1.0 Branch → Trunk
Comment 10 is an interesting idea, but that definitely sounds like a separate
bug.  See if such a bug has already been filed, and if not, go ahead and file one.

The UI that Wolfgang describes in comment 15 sounds quite reasonable to me.
Attached patch alternative fix (obsolete) — Splinter Review
This is an alternative approach. All I'm doing here is making the desktop
directory be a universal cross-platform directory exported by
nsDirectoryService. On Unix it's $HOME/Desktop if that exists, otherwise just
$HOME. I've done some cleanup in the Firefox download manager to actually use
it on Unix. What do people think about this?
Comment on attachment 173140 [details] [diff] [review]
alternative fix

Darin, could you review the XPCOM parts of this patch? This is old code and I
don't know who owns it anymore, if anyone.
Attachment #173140 - Flags: review?(darin)
Comment on attachment 173140 [details] [diff] [review]
alternative fix

>Index: xpcom/io/SpecialSystemDirectory.cpp

>+    return NS_NewNativeLocalFile(nsDependentCString(PR_GetEnv("HOME")), 

PR_GetEnv returns NULL when the variable is not defined, and
nsDependentCString(0) crashes.	Should we care?


>+        case Unix_DesktopDirectory:
...
>+            rv = home->AppendNative(NS_LITERAL_CSTRING("Desktop"));

Is this directory ever localized?  Or, is it possible for users to
configure GNOME to name this differently?  I know that "Desktop" is
what it is on my system, but is that universal?  Does KDE use this
too?  Is it part of some Linux desktop specification that we could
reference here?


>Index: xpcom/io/nsDirectoryService.cpp

>     { NS_OS_DRIVE_DIR,             &nsDirectoryService::sOS_DriveDirectory },
>     { NS_OS_TEMP_DIR,              &nsDirectoryService::sOS_TemporaryDirectory },
>     { NS_OS_CURRENT_PROCESS_DIR,   &nsDirectoryService::sOS_CurrentProcessDirectory },
>     { NS_OS_CURRENT_WORKING_DIR,   &nsDirectoryService::sOS_CurrentWorkingDirectory },
>+    { NS_OS_HOME_DIR,              &nsDirectoryService::sHomeDirectory },
>+    { NS_OS_DESKTOP_DIR,           &nsDirectoryService::sDesktopDirectory },

nit: convention for NS_OS_ seems to be to map it to sOS_, so
want to do the same here?


>-    else if (inAtom == nsDirectoryService::sUserDesktopDirectory)
>+    else if (inAtom == nsDirectoryService::sUserDesktopDirectory
>+             || inAtom == nsDirectoryService::sDesktopDirectory)

nit: coding convention for this file seems to put '||' on first
line instead of a start of next line.


>-    else if (inAtom == nsDirectoryService::sDesktopdirectory)
>+    else if (inAtom == nsDirectoryService::sDesktopdirectory
>+             || inAtom == nsDirectoryService::sDesktopDirectory)

ditto


>Index: xpcom/io/nsDirectoryServiceDefs.h

>+// This gives the same thing as NS_OS_DESKTOP_DIR
>     #define NS_WIN_DESKTOP_DIRECTORY            "DeskP" // file sys dir which physically stores objects on desktop

So, any guess why it exists?  Should we make it equal to "Desk"
instead?  Or, maybe better to preserve "DeskP" for backwards
compat just in case (since this file is included in the Gecko SDK).


>Index: toolkit/mozapps/downloads/content/downloads.js
>Index: toolkit/mozapps/downloads/content/pref-downloads.js
>Index: toolkit/mozapps/downloads/src/nsHelperAppDlg.js.in

I didn't review the changes to these files.
KDE allows the user to configure the "Desktop" directory to any arbitrary
directory. Also, it allows for a setting where no files are shown on the desktop
so even if that directory receives files they will not be visible. Many other
often used Window managers do not even have to concept of showing files on the
desktop or also allow for a configuration where no files are shown. 

For these reasons, the default download method on Linux should never be to the
desktop and if the user chooses to download to the desktop, the location should
be specifyable by the user (~/Desktop is a good default for the location though),
(In reply to comment #20)
> (From update of attachment 173140 [details] [diff] [review] [edit])
> >Index: xpcom/io/SpecialSystemDirectory.cpp
> 
> >+    return NS_NewNativeLocalFile(nsDependentCString(PR_GetEnv("HOME")), 
> 
> PR_GetEnv returns NULL when the variable is not defined, and
> nsDependentCString(0) crashes.	Should we care?

This is ancient code that I only moved. So, I don't care :-)

> >+        case Unix_DesktopDirectory:
> ...
> >+            rv = home->AppendNative(NS_LITERAL_CSTRING("Desktop"));
> 
> Is this directory ever localized?  Or, is it possible for users to
> configure GNOME to name this differently?  I know that "Desktop" is
> what it is on my system, but is that universal?  Does KDE use this
> too?  Is it part of some Linux desktop specification that we could
> reference here?

Apparently GNOME does not allow the name to be changed. KDE uses Desktop by
default; I don't know whether it can be changed in KDE. Apparently there is no
formal spec for this yet. I think guessing "Desktop" is as good as we can do.

> >Index: xpcom/io/nsDirectoryService.cpp
> 
> >     { NS_OS_DRIVE_DIR,             &nsDirectoryService::sOS_DriveDirectory },
> >     { NS_OS_TEMP_DIR,             
&nsDirectoryService::sOS_TemporaryDirectory },
> >     { NS_OS_CURRENT_PROCESS_DIR,  
&nsDirectoryService::sOS_CurrentProcessDirectory },
> >     { NS_OS_CURRENT_WORKING_DIR,  
&nsDirectoryService::sOS_CurrentWorkingDirectory },
> >+    { NS_OS_HOME_DIR,              &nsDirectoryService::sHomeDirectory },
> >+    { NS_OS_DESKTOP_DIR,           &nsDirectoryService::sDesktopDirectory },
> 
> nit: convention for NS_OS_ seems to be to map it to sOS_, so
> want to do the same here?

OK I'll do that.

> >-    else if (inAtom == nsDirectoryService::sUserDesktopDirectory)
> >+    else if (inAtom == nsDirectoryService::sUserDesktopDirectory
> >+             || inAtom == nsDirectoryService::sDesktopDirectory)
> 
> nit: coding convention for this file seems to put '||' on first
> line instead of a start of next line.

OK

> >Index: xpcom/io/nsDirectoryServiceDefs.h
> 
> >+// This gives the same thing as NS_OS_DESKTOP_DIR
> >     #define NS_WIN_DESKTOP_DIRECTORY            "DeskP" // file sys dir
which physically stores objects on desktop
> 
> So, any guess why it exists?  Should we make it equal to "Desk"
> instead?  Or, maybe better to preserve "DeskP" for backwards
> compat just in case (since this file is included in the Gecko SDK).

Right. It means exactly the same thing as "Desk"; I'm keeping it for backward
compatibility with any existing extensions or embedders.
(In reply to comment #21)
> KDE allows the user to configure the "Desktop" directory to any arbitrary
> directory. Also, it allows for a setting where no files are shown on the
> desktop so even if that directory receives files they will not be visible.
> Many other often used Window managers do not even have to concept of showing
> files on the desktop or also allow for a configuration where no files are
> shown.
> 
> For these reasons, the default download method on Linux should never be to the
> desktop and if the user chooses to download to the desktop, the location
> should be specifyable by the user (~/Desktop is a good default for the
> location though),

We already have an option to choose the location of the download; we don't need two.

I suggest that this code be used for "Desktop" and the default Unix download
pref be changed to "ask me every time". Distributors can override that pref if
they know their users have a "Desktop" directory.
Attached patch XPCOM changesSplinter Review
Here's the updated patch.

If we want to later include sniffing for KDE or other window managers, to
locate their Desktop directories, we could do that here. But I think this is a
reasonable first step.
Attachment #173140 - Attachment is obsolete: true
Attachment #173671 - Flags: superreview?(darin)
Attachment #173671 - Flags: review?(darin)
Comment on attachment 173671 [details] [diff] [review]
XPCOM changes

>Index: xpcom/io/nsDirectoryServiceDefs.h

>+// Files stored in this directory will appear on the user's desktop,
>+// if there is one, otherwise it's just the same as "Home"
>+#define NS_OS_DESKTOP_DIR                       "Desk"
> 
> /* Property returns the directory in which the procces was started from.  
>  * On Unix this will be the path in the MOZILLA_FIVE_HOME env var and if 
>  * unset will be the current working directory. 

nit: let's use a consistent commenting style in this file :)


r+sr=darin
Attachment #173671 - Flags: superreview?(darin)
Attachment #173671 - Flags: superreview+
Attachment #173671 - Flags: review?(darin)
Attachment #173671 - Flags: review+
Attachment #173140 - Flags: review?(darin)
Attached patch Firefox UI fixSplinter Review
Now that "Desk" is supported on all platforms, use it as the download directory
when "Desktop" is selected. And make the JS logic more consistent by always
using "Downloads" as the parameter to getSpecialFolderKey to get the Downloads
directory.
Attachment #175875 - Flags: review?(mconnor)
Comment on attachment 175875 [details] [diff] [review]
Firefox UI fix

Looks good.  Not sure how it'll work with the new UI on GTK2 builds, since I
haven't poked it since Prefwindow V landed.
Attachment #175875 - Flags: review?(mconnor) → review+
Checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
/me wonders what impact will this have on bug 227117
Flags: blocking-aviary1.1?
Target Milestone: --- → Firefox1.1
Should have no impact on any platform but Unix, i.e., no impact on Mac.
vrfy'd fixed using 2005052410-trunk (deer park) bits on linux fc3.
Status: RESOLVED → VERIFIED
actually, I might've spoken too soon: I think this fix caused a regression where
autodownloading disregards the "always ask me where to save" pref. I'll file a
bug on that (couldn't find an open one)...
filed bug 295402 for the regression I saw wrt autodownloading.
has this caused bug 300856?
Possibly, or it could be the fix to bug 284089. Try builds from different dates
to see which one it is.
*** Bug 102741 has been marked as a duplicate of this bug. ***
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: