opening "main" preferences pane creates ~/Desktop even when not set to download directory

NEW
Unassigned

Status

()

--
minor
11 years ago
a year ago

People

(Reporter: pk1, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008051807 Firefox/3.0
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9) Gecko/2008051807 Firefox/3.0

When opening the preferences dialogue and going to the main pane, a ~/Desktop directory is created. I also tested with the "mozilla-firefox-bin-3.0_rc1" in gentoo, which is the version that is released by mozilla. The problem persisted. 

Reproducible: Always

Steps to Reproduce:
1. Open preferences 
2. Goto "Main" pane
Actual Results:  
~/Desktop created

Expected Results:  
There should be no ~/Desktop

Comment 1

11 years ago
I can confirm this with a recent trunk build.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Version: unspecified → Trunk

Comment 2

11 years ago
This is strange:
Yesterday, this happened every time I tried. Now, I'm unable to reproduce it at all.
(Reporter)

Comment 3

11 years ago
Are you switching to the "Main" preference pane? For me it only occurs on that pane (and not the other ones, e.g. Security or Advanced). 

Comment 4

11 years ago
Yes, this happened when switching to the "Main" pane. It only happened the first time I switched to the "Main" pane:
  * Edit -> Preferences
  * go to "Main" pane, if not already there (creates ~/Desktop)
  * rm -r ~/Desktop
  * go to other pane
  * go to "Main" pane (does not create ~/Desktop)

That was yesterday. Today I have tried to investigate the bug, but I can't even reproduce it any more.
(Reporter)

Comment 5

11 years ago
weird... I can still consistently produce it. 

Comment 6

10 years ago
I'm seeing this with the recent trunk nightlies in Windows.

Comment 7

10 years ago
Could someone with permission to edit things mark #482662 and #479191 as duplicates of this bug?

Also, this is Debian bug #487842
Duplicate of this bug: 482662
Component: Preferences → Download Manager
Product: Firefox → Toolkit
QA Contact: preferences → download.manager
Duplicate of this bug: 479191
(Reporter)

Comment 10

10 years ago
Note: this same behavior occurs for me when switching to the "Attachments" pane in Thunderbird 3.0 Beta 3: Bug #511271
Blocks: 511271

Comment 11

9 years ago
To avoid this happening  create a text file ~/.config/user-dirs.dirs and in it place 

XDG_DESKTOP_DIR="/home/linux_user/"

Where linux_user is your user name.

Other XDG_*_DIR settings
XDG_DOWNLOAD_DIR="/home/linux_user/downloads"
XDG_TEMPLATES_DIR="/home/linux_user/"
XDG_PUBLICSHARE_DIR="/home/linux_user/"
XDG_DOCUMENTS_DIR="/home/linux_user/docs"
XDG_MUSIC_DIR="/home/linux_user/music"
XDG_PICTURES_DIR="/home/linux_user/pics"
XDG_VIDEOS_DIR="/home/linux_user/vids"

References http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html and http://support.mozilla.com/tiki-view_forum_thread.php?locale=en-US&comments_parentId=428359&forumId=1

Updated

9 years ago
Duplicate of this bug: 507579
It seems to me that we should only create the default download directory if and when we are actually going to save a file into it.
As written in "Unable to save or download files"(an MozillaZine Knowledge Base document), download location, download location selection, is affeced by next setting.  
> http://kb.mozillazine.org/Unable_to_save_or_download_files#Reset_download_folder
>   * browser.download.dir
>   * browser.download.downloadDir
>   * browser.download.folderList
>   * browser.download.lastDir
>   * browser.download.useDownloadDir
See next document for each setting.
> https://developer.mozilla.org/en/Download_Manager_preferences
> Note: browser.download.downloadDir is not seen in this document and about:config)

Sufficiantly confusing, but roughly next;
> browser.download.useDownloadDir=false : Always Ask
> browser.download.useDownloadDir=true  : Save file to
>   - browser.download.folderList=0 :
>       indicates the Desktop; (Default of Fx 3.0 or earlier, and Tb) 
>   - browser.download.folderList=1 :
>       indicates the systems default downloads location; (Default of Fx 3.5 or later, and Seamonkey) 
>   - browser.download.folderList=2 :
>       indicates a custom (see: browser.download.dir) folder.
>   If existent folder is selected via UI at "Save file to",
>      browser.download.folderList is changed to 2, and, pointer to selected
>      folder is saved in browser.download.dir.         
>   Once browser.download.folderList=2 is set, it wont't be changed via UI. 

Above is easily be observed by reset of all five prefs.js settings via about:config/Config Editor, change download setting at Preference/Options UI, and check above five settings via about:config/Config Editor.

If browser.download.folderList=0 is set, a ~/Desktop directory may be created.
Next is probably easiest recovery procedure when a ~/Desktop directory was created.
  Select a directory via UI(force folderList=2), if you want to use
  "Save file to"(useDownloadDir=true), and delete created ~/Desktop.
Another workaround is;
  browser.download.folderList=1, if system's download locationsetting can be
  used. If system's download directory setting can not be used, set it to one
  you want, like comment #11.
  (if Mac OS X, it seems to depend on OS version and environment.)

(off-topic)
Because one of next is used as fall back directory when specified directry(for example, browser.download.lastDir) is not found(or no write permission, ....),
  (a) browser.download.dir (currently, this is probably used), 
  (b) most recently used directory,
  (c) current directory(working directory),
browser.download.dir shouldn't be set to directory on USB memory or removable drive. If you want to set directory on network file server in browser.download.dir, please take care for network error or server down.
Duplicate of this bug: 614559
Duplicate of this bug: 775026

Updated

5 years ago
Duplicate of this bug: 762821

Comment 18

5 years ago
It is being created on start-up now: bug 922719.  Maybe that's because of Reset Firefox?

Updated

4 years ago
See Also: → bug 922719
You need to log in before you can comment on or make changes to this bug.