download-helper label hard coded instead of respecting XDG_DOWNLOAD_DIR
Categories
(Firefox :: Settings UI, defect)
Tracking
()
People
(Reporter: jontajonta, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Steps to reproduce:
- ~/.config/user-dirs.dirs has the line
XDG_DOWNLOAD_DIR="$HOME/downloads"(Note the lower-case "d") - New Firefox-profile
- about:preferences
- Files and applications
- Downloads
- Save files to
Actual results:
"Downloads"
Expected results:
"downloads"
(More important if one sets XDG_DOWNLOAD_DIR to something very different, of course)
This seems like the relevant code:
download-header = Downloads
in
1st commit containing it:
(Woops. Forgot about Markdown. Parenthesis as heading is unintentional)
|
||
Comment 2•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Preferences' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
I was able to reproduce On My ubuntu 20 64bit the user-dirs.dirs has XDG_DOWNLOAD_DIR="$HOME/Downloads so i changed it with another folder name.
Then created new profiles for Firefox release 91.0.2, beta 92 and nightly 93.0a1 and firefox always showed me "Downloads" in about preferences
|
||
Comment 4•4 years ago
|
||
(In reply to Jonathan from comment #0)
This seems like the relevant code:
download-header = Downloads
in
https://searchfox.org/mozilla-central/source/browser/locales/en-US/browser/preferences/preferences.ftl
This reference is just user-facing text and won't get used in determining any logic for the browser. I looked through our codebase and don't see any hardcoding of XDG_DOWNLOAD_DIR nor casing.
Martin, any idea what is happening here?
|
||
Comment 5•4 years ago
|
||
Yes, we don't use XDG_DOWNLOAD_DIR env variable. It's just not implemented.
|
|
||
Comment 6•4 years ago
|
||
The code is here:
https://searchfox.org/mozilla-central/rev/8db61933e64b13c4a0ae456bcaccbd86a519ccc5/toolkit/components/downloads/DownloadIntegration.jsm#317
Although we define:
#define NS_OS_DEFAULT_DOWNLOAD_DIR "DfltDwnld"
It doesn't seem to be implemented at https://searchfox.org/mozilla-central/source/toolkit/xre/nsXREDirProvider.cpp
|
|
||
Comment 7•4 years ago
|
||
nsXREDirProvider::GetFile() may be a correct place to add it.
|
||
Comment 8•4 years ago
|
||
We do honour this, I believe. Specifically, the unix implementation of DfltDwnld is at https://searchfox.org/mozilla-central/rev/eecd2dd4ba630bea4ce103623a4bfb398065b64b/xpcom/io/nsDirectoryService.cpp#449-452, which uses:
GetSpecialSystemDirectory(Unix_XDG_Download, getter_AddRefs(localFile));
which in turn ends up at https://searchfox.org/mozilla-central/rev/eecd2dd4ba630bea4ce103623a4bfb398065b64b/xpcom/io/SpecialSystemDirectory.cpp#606
return GetUnixXDGUserDirectory(aSystemSystemDirectory, aFile);
which uses the yucky-looking-but-probably-working code at https://searchfox.org/mozilla-central/rev/eecd2dd4ba630bea4ce103623a4bfb398065b64b/xpcom/io/SpecialSystemDirectory.cpp#348-370
static const char xdg_user_dirs[] =
"DESKTOP\0"
"DOCUMENTS\0"
"DOWNLOAD\0"
"MUSIC\0"
"PICTURES\0"
"PUBLICSHARE\0"
"TEMPLATES\0"
"VIDEOS";
static const uint8_t xdg_user_dir_offsets[] = {0, 8, 18, 27, 33, 42, 54, 64};
static nsresult GetUnixXDGUserDirectory(SystemDirectories aSystemDirectory,
nsIFile** aFile) {
char* dir = xdg_user_dir_lookup(
xdg_user_dirs +
xdg_user_dir_offsets[aSystemDirectory - Unix_XDG_Desktop]);
nsresult rv;
nsCOMPtr<nsIFile> file;
if (dir) {
rv = NS_NewNativeLocalFile(nsDependentCString(dir), true,
getter_AddRefs(file));
The summary of this bug is quite specific, and it is about the user-facing label in prefs being localized to "Downloads" because it's the OS-configured downloads folder, irrespective of the actual name of the folder or the path.
This is a duplicate.
Description
•