Closed Bug 922719 Opened 11 years ago Closed 1 year ago

Linux: empty Desktop directory created on startup

Categories

(Firefox :: General, defect)

x86
Linux
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: u474838, Unassigned)

References

Details

(Whiteboard: [DUPEME?][bugday-20131007])

User Agent: Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20131001030204

Steps to reproduce:

Start Firefox Nightly Trunk (27)


Actual results:

Empty ~/Desktop is created


Expected results:

No ~/Desktop should be created.

I don't have and don't use ~/Desktop and the other xdg directories. So it's annoying I have to rmdir ~/Desktop after Firefox has started.
Confirmed with 2013-10-06-03-02-01-mozilla-central-firefox-27.0a1.en-US.linux-x86_64.

There is bug 434327 for download-related creation of the directory (when the Preferences window is opened).  But now it is being created on start-up.

Reset Firefox puts its backup into the directory (undocumented, bug 921462).

From bug 434327 comment 11: you can specify a different directory as the desktop directory in XDG user-dirs.dirs.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [DUPEME?][bugday-20131007]
(In reply to Aleksej [:Aleksej] from comment #1)
> Confirmed with
> 2013-10-06-03-02-01-mozilla-central-firefox-27.0a1.en-US.linux-x86_64.
> 
> There is bug 434327 for download-related creation of the directory (when the
> Preferences window is opened).  But now it is being created on start-up.
> 
> Reset Firefox puts its backup into the directory (undocumented, bug 921462).

FWIW I didn't Reset Firefox in this profile.

> From bug 434327 comment 11: you can specify a different directory as the
> desktop directory in XDG user-dirs.dirs.

browser.download.dir is not ignored on download here.

Are you saying there's a way to configure XDG user-dirs.dirs and
customize ~/Desktop to something else?
(In reply to Carsten Mattner from comment #2)
> FWIW I didn't Reset Firefox in this profile.

It happens with a new profile.  I mentioned Reset Firefox because it's a new feature that uses a desktop directory (while the download manager possibly does not).

> > From bug 434327 comment 11: you can specify a different directory as the
> > desktop directory in XDG user-dirs.dirs.
> 
> browser.download.dir is not ignored on download here.
> 
> Are you saying there's a way to configure XDG user-dirs.dirs and
> customize ~/Desktop to something else?

Yes, see bug 434327 comment 11 (the variable is XDG_DESKTOP_DIR).
The XDG_DESKTOP_DIR workaround doesn't work for me. Do I need to consider anything else than setting it before starting Firefox?
As described in 956709 - it creates ~/Desktop ignoring your XDG_DESKTOP_DIR value. Even if you have different locales and Desktop should be named somehow different, it just creates ~/Desktop.
A workaround as posted by Ninguém at https://support.mozilla.org/en-US/questions/985990:
"If I change the line I mentioned earlier from XDG_DESKTOP_DIR="$HOME" to XDG_DESKTOP_DIR="/home/username" solved the problem."

The above workaround has solved the problem for me (on Ubuntu 14.04 x64).
There are several related problems here:

  - it's ignoring the XDG_DESKTOP_DIR variable from the environment
  - it doesn't parse ~/.config/user-dirs.dirs properly ($HOME must have a trailing slash)
  - it also ignores /etc/xdg/user-dirs.defaults

The bug is mostly due to the way xdg_user_dir_lookup is implemented.

(I'm curious though: why does Firefox need ~/Desktop at startup?)
To clarify the workaround:

1. If it doesn't exist yet, create ~/.config/user-dirs.dirs
2. Fill it with XDG_DESKTOP_DIR="/home/YourUserName"
3. Make sure to use an absolute path, not ~ or $HOME

Hope this helps.
QA Whiteboard: [bugday-20150216]
Component: Untriaged → General
See Also: → 434327, 921462
This now also happens in Thunderbird (31.4.0)
Any progress regarding a fix?
This still persists. Ping?
The directory also gets created whenever one opens a Browse dialog to upload stuff (as said in #
956709 but the info was not in this report).
I think the issue is with the trailing / in line 318 of xpcom/io/SpecialSystemDirectory.cpp

    if (strncmp(p, "$HOME/", 6) == 0) {

The / should be considered part of the relative path, not part of the base. https://www.freedesktop.org/wiki/Software/xdg-user-dirs/ does state:

> To disable a directory, point it to the homedir.

So it’s expected that users put "$HOME" (no slash) in there.
For what it's worth my $XDG_DESKTOP_DIR points to a subdirectory of $HOME, not root (aka ~).
I'm also being annoyed by this issue. I like to clean my home clean, and I've deleted this garbage directory that Firefox created literally hundreds (probably thousands) of times.

It seems to be created both at startup and at some point during runtime (eg: I've seen it get re-created without restarting Firefox). Apparently, #434327.

I've set `XDG_DESKTOP_DIR="$HOME"`, so this should not be happening.

Both issues are reproducible under a clean profile. If there anything we can do to help get this cleared up faster? Anything worth testing, etc?
(In reply to Hugo Osvaldo Barrera from comment #19)
> I've set `XDG_DESKTOP_DIR="$HOME"`, so this should not be happening.

You need to put a trailing slash, unfortunately.
As of Firefox 57.0.4 no setting of XDG_DESKTOP_DIR in ~/.config/user-dirs.conf seems to prevent Firefox from creating the Desktop directory -- neither "$HOME" nor "$HOME/" nor "/home/user".  Also, setting "enabled=False" in user-dirs.conf does not help (and it should).  Is there any workaround which actually works, considering this simple bug hasn't been fixed for over 4 years?  I have now added "rm -rf ~/Desktop" to my .bashrc... clearly not an ideal solution.
Can confirm the issue persists.
Severity: normal → S3

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:mossop, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(dtownsend)

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.

Flags: needinfo?(dtownsend)

In bug 434327 people can't seem to repro so I'm going to close this out. Please reopen or refile if you're still seeing this.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.