Last Comment Bug 259356 - Support for the Freedesktop.org XDG Base Directory Specification
: Support for the Freedesktop.org XDG Base Directory Specification
Status: REOPENED
parity-chrome
:
Product: Core
Classification: Components
Component: General (show other bugs)
: Trunk
: All Linux
: -- enhancement with 60 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
:
Mentors:
http://standards.freedesktop.org/base...
: 393199 525841 923923 user_directories (view as bug list)
Depends on:
Blocks: 140751 726939 735285 818686 903874 239254
  Show dependency treegraph
 
Reported: 2004-09-14 12:30 PDT by Mircea Bardac (IceRAM)
Modified: 2016-11-24 02:50 PST (History)
65 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
add support for the XDG base directories to the directory service (18.96 KB, patch)
2008-03-21 13:38 PDT, Christian Persch (GNOME) (away; not receiving bug mail)
no flags Details | Diff | Splinter Review
Updated to latest trunk (13.83 KB, patch)
2013-01-17 07:41 PST, Martin Stránský
mh+mozilla: review-
Details | Diff | Splinter Review

Description Mircea Bardac (IceRAM) 2004-09-14 12:30:29 PDT
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040804 Firefox/0.9.3
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040804 Firefox/0.9.3

Firefox should support [1] under Linux. This means using the variables defined
there for storing config files, data files and cache files. It would be nice for
a good desktop integration under X (Linux) to follow these specs (because I've
also noticed Firefox follows others too).

This might not require many lines in the code, but will require moving some
config & data files from ~/.phoenix to probably $XDG_CONFIG_HOME/phoenix and
$XDG_CACHE_HOME/phoenix (& even $XDG_DATA_HOME/phoenix), depending on the needs.

[1] http://freedesktop.org/Standards/basedir-spec (current version 0.6)

Reproducible: Always
Steps to Reproduce:
Comment 1 logan 2004-09-14 14:16:43 PDT
Hardware -> All, Severity -> enhancement, marking NEW

This is pretty low-level stuff, Product -> Browser?
Comment 2 Mircea Bardac (IceRAM) 2004-09-14 14:47:28 PDT
Err... this is the first that came to my mind.
Sorry for not thinking globally but at the time I wrote the bug-report (actually
a feature)...

Yes, this should apply to all the Mozilla apps... unfortunately, I don't know
exactly which product that would be that matches all of them. I'll switch it to
"Browser" for now.

Note: if Browser reffers to the internals (cache etc) and Firefox to the
externals (GUI etc), maybe both should be selected. This is kind of tricky. I'll
leave the choice to someone more experienced than me in these projects.
Comment 3 logan 2004-09-14 16:37:54 PDT
(In reply to comment #2)
> Note: if Browser reffers to the internals (cache etc) and Firefox to the
> externals (GUI etc), maybe both should be selected. This is kind of tricky. I'll
> leave the choice to someone more experienced than me in these projects.

Sorry, that wasn't directed at you, but some of the higher-ups.

If made, this kindof change would probably be done in Mozilla, which would carry
over to Firefox. Just need some functions to return the initial starting point,
then append 'mozilla' or 'mozilla/firefox' to that.
Comment 4 Phil Ringnalda (:philor) 2006-05-29 19:08:20 PDT
Well, no, not Browser/Suite. Since it's asking that we locate the profile and default download directory based on env vars, things which Firefox and Seamonkey do separately, choosing different places, there's no single place to cover both products.
Comment 5 Mircea Bardac (IceRAM) 2006-05-29 23:08:45 PDT
Hmm.. then.. shouldn't this bug be duplicated for other Mozilla apps too?
Comment 6 Sylvain Pasche 2007-08-23 05:41:23 PDT
*** Bug 393199 has been marked as a duplicate of this bug. ***
Comment 7 antistress 2008-03-11 06:37:07 PDT
This bug is quite important since Linux-users can't easily backup their config & data files if these files are not stored at the right place

see that article for an illustration : 
Cleaning user preferences, keeping user data
http://ploum.frimouvy.org/?184-cleaning-user-preferences-keeping-user-data
Comment 8 Rimas Kudelis 2008-03-11 08:41:26 PDT
I tI think we depend on Bug 399500 here.
Comment 9 Christopher Aillon (sabbatical, not receiving bugmail) 2008-03-11 10:32:57 PDT
Actually, it's more of a dupe... (technically the other should have been duped here, but that one has a patch already, so duping up...)

*** This bug has been marked as a duplicate of bug 399500 ***
Comment 10 antistress 2008-03-11 11:14:45 PDT
Could please check if these two bugs are about the same things ? 

Bug 399500 seems to be about choosing the good directory when firefox downloads a file, but xdg freedesktp specs are also about where installing date & configuration files when Firefox itself is installed :

The default for $XDG_CONFIG_HOME is $HOME/.config, the default for $XDG_DATA_HOME is $HOME/.local/share. So all applications should look for those environment variables and use those default values if the variables are not set.

that's why i've made comment#7 above concerning backup

Are this bug and bug 399500 really duplicates ?
Comment 11 Rimas Kudelis 2008-03-11 12:20:54 PDT
In reply to Comment #10:
Yeah, that's why I said in bug 399500 comment 11 that I'm not even sure anymore that this bug depends on bug 399500. They are similar, but address different problems.
Comment 12 Christopher Aillon (sabbatical, not receiving bugmail) 2008-03-11 12:25:21 PDT
Ugh, not enough coffee.  I was looking at the summary and ignored what the bug was actually about.  Fixing summary to be more explicit and unduping.  Sorry for the noise.
Comment 13 Rimas Kudelis 2008-03-11 12:32:39 PDT
Here, let's make the summary even better, and fix the URL field.
Comment 14 antistress 2008-03-11 15:03:45 PDT
well i think that the title and the description of this bug are both ok, whereas the title og bug 399500 is unclear 
Comment 15 Christian Persch (GNOME) (away; not receiving bug mail) 2008-03-21 13:38:29 PDT
Created attachment 311040 [details] [diff] [review]
add support for the XDG base directories to the directory service

(Actually making use of these directories for the profile/local profile paths will be a further patch.)
Comment 16 Juliano F. Ravasi 2008-04-30 19:34:12 PDT
Now, it is necessary to define which files should go to which directories.

For example, for Firefox, ~/.mozilla/firefox/<profile>/ currently contains a mess of configuration, data and cache files that must be separated and organized into something like:

$XDG_CONFIG_HOME/firefox/<profile>/   (config files)
$XDG_DATA_HOME/firefox/<profile>/     (data files)
$XDG_CACHE_HOME/firefox/<profile>/    (browser cache)

It is easy to define what should go to the cache directory, but for everything else, there are some ambiguities about what is configuration and what is data.

Extensions, dictionaries, chrome and password files are a few things that may fit in either directory, depending on how you consider them.
Comment 17 antistress 2009-04-15 15:13:29 PDT
Bug 399498 -  use XDG downloads dir as default downloads dir  
has been fixed and it's great 

But what about the present bug which concerns where installing data &
configuration files when Firefox itself is installed ?
Comment 18 Aaron Whitehouse 2010-01-29 01:15:24 PST
In a similar vein to Comment 7, an additional issue that this bug causes is that backup programs like Deja Dup automatically exclude the XDG_CACHE_HOME directory, whereas the pathname for Firefox's cache is always different.
https://answers.launchpad.net/deja-dup/+question/99015
Comment 19 Aaron Whitehouse 2010-02-02 23:57:02 PST
Also, Firefox should use $XDG_CACHE_HOME for both the cache folder and the urlclassifier3.sqlite folder.
Comment 20 Nickolay_Ponomarev 2010-04-12 11:59:41 PDT
*** Bug 525841 has been marked as a duplicate of this bug. ***
Comment 21 lh 2010-10-11 06:46:38 PDT
i have applied that patch, but firefox still using ~/.mozilla. anyone have workable patch to get rid of ~/.mozilla?
Comment 22 antistress 2011-04-02 16:12:09 PDT
That would be great if a fix could happen for Firefox 6 (since Firefox 5 is about to get its code frozen)
Integration within Linux is important and this would allow better backups and so on
Thanks in advance
Comment 23 mike 2011-06-30 07:12:46 PDT
(In reply to comment #19)
> Also, Firefox should use $XDG_CACHE_HOME for both the cache folder and the
> urlclassifier3.sqlite folder.

Yes, it really should. urlclassifier3.sqlite can be a pain for anyone who has to deal with a home directory with a quota applied to it.

Firefox should put everything which it will currently put in to XRE_PROFILE_LOCAL_PATH (if you can persuade Firefox to use it) in to a sub directory of XDG_CACHE_HOME. The Mac OS X version of Firefox effectively does this already and has done for years. It puts Cache, urlclassifier etc  in  ~/Library/Caches/Firefox


Someone has recently submitted a patch for using XDG_CACHE_HOME on a different bug https://bugzilla.mozilla.org/show_bug.cgi?id=239254#c8
Comment 24 Ilia K. 2011-07-01 14:42:03 PDT
(In reply to comment #23)
> Someone has recently submitted a patch for using XDG_CACHE_HOME on a
> different bug https://bugzilla.mozilla.org/show_bug.cgi?id=239254#c8

It was me :) I'm currently waiting for the review.
I'm using firefox with the patch from Bug 239254 applied and have the following files under ~/.cache/mozilla/firefox/<salt>.<profile_name>
  Cache/
  startupCache/
  urlclassifier3.sqlite
  XUL.mfasl
The above directory is seen as a "local data directory" just like if it was specified by XRE_PROFILE_LOCAL_PATH, but the patch works for all profiles.

While the patch attached in comment #15 exposes XDG-related directories to the rest of the code, the patch in bug 239254 actually determines the path to use (by default). When the former is committed the later may make use of new API, but currently it's just "hard-coded" to use XDG_CACHE_HOME environment variable and fall back to "~/.cache".
Comment 25 Stephan Sokolow 2011-07-10 16:09:27 PDT
(In reply to comment #16)
> It is easy to define what should go to the cache directory, but for
> everything else, there are some ambiguities about what is configuration and
> what is data.
> 
> Extensions, dictionaries, chrome and password files are a few things that
> may fit in either directory, depending on how you consider them.

I remember running across a good explanation of how to look at the split a couple of months ago.

"config" is stuff that is more likely to be specific to a given system and, if you lose it, it's not the end of the world. (Basically, stuff that may be omitted from a roaming profile under certain circumstances)

"data" is stuff that's irreplaceable and should always roam if at all possible. (eg. bookmarks, saved sessions, and so on)

I'd say that, based on that rationale, password stores, personal dictionaries, and the like are definitely data and a decent case could be made for putting any extensions without platform-specific components in data as well.
Comment 26 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2011-08-09 00:15:21 PDT
See http://code.google.com/p/chromium/issues/detail?id=16976.
Comment 27 Hugo Osvaldo Barrera 2012-02-03 17:01:31 PST
While this issue is set to "platform: all linux", this issue applies to all unix-like OSs, except MAC OS X (I'm mentioning this just in case this gets commited to somewhere that excludes other OSs).

By the way, the latest spec is 0.7: http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

I've also seen no mention of $XDG_RUNTIME_DIR. Just in case, this is where user-specific runtime files should be stored (ie: sockets).
Comment 28 Tristan Miller 2012-03-13 09:48:40 PDT
The same issue has been raised for Thunderbird as Bug 735285.
Comment 29 sbastig 2012-08-23 00:24:30 PDT
Just giving this a bump. Is this still on the agenda?
Comment 30 faipasierch 2012-11-21 04:19:14 PST
* ping
Comment 31 Leo Gaspard [:ekleog] 2012-12-28 15:39:08 PST
Well... Just bumping this again !
Comment 32 Eric Heintzmann 2013-01-05 02:11:04 PST
According to XDG Base directory specification, Firefox should not have its own folder anymore:
User data should go into $XDG_DATA_HOME (which default to ~/.local/share),
user preferences should go into $XDG_CONFIG_HOME (which default to ~/.config)
and cached data should go to $XDG_CACHE_HOME (which default to ~/.cache).
More details at :
http://ploum.net/post/207-modify-your-application-to-use-xdg-folders
https://live.gnome.org/GnomeGoals/XDGConfigFolders

Full specification can be found at: 
http://standards.freedesktop.org/basedir-spec/latest/

The Freedesktop.org XDG base directory specification have good de facto adoption.
It has been adopted by:
- GNOME ( https://live.gnome.org/GnomeGoals/XDGConfigFolders )
- GTK+ ( https://bugzilla.gnome.org/show_bug.cgi?id=646631 )
- KDE ( http://techbase.kde.org/KDE_System_Administration/XDG_Filesystem_Hierarchy#Freedesktop.org_and_Standard_Directories )
- QT ( http://harmattan-dev.nokia.com/docs/library/html/qt4/qsettings.html#setPath )
- XFCE ( http://docs.xfce.org/xfce/xfce4-session/advanced in Files and Environment Variables )
- LXDE
- Razor-qt
- VLC ( https://trac.videolan.org/vlc/ticket/1267 )
- GStreamer ( https://bugzilla.gnome.org/show_bug.cgi?id=518597 )
- Chrome ( http://code.google.com/p/chromium/issues/detail?id=16976 )
- many more upstream applications
- Ubuntu ( http://brainstorm.ubuntu.com/idea/6557/ & http://packages.ubuntu.com/fr/source/precise/libxdg-basedir )
- Debian ( http://packages.debian.org/squeeze/libxdg-basedir1 )
- Red Hat
- Fedora
- Suse
- many more distributions

I think that Firefox should use same locations than the vast majority of Desktop environment and applications.


There are real advantages of following this specification :
- a lot less cluttered $HOME
- Make backups a lot more safer and easier.
  Backuping your $XDG_DATA_HOME along with your files is enough 
  (or just excluding $XDG_CACHE_HOME)
- A lot easier to reset a default configuration if you want/need it (and 
  without any risk to loose informations). Even for the software itself 
  could choose to reset $XDG_CONFIG_HOME if needed.
- Avoid some strange bugs that happens because you had a old version of 
  some configuration file
- A lot more of flexibility and portability because no path are hardcoded.
Comment 33 vulcain 2013-01-05 11:34:50 PST
The problem with XDG Base Directory Specification is that broken the copy of profile. 
When we swift windows to Linux, it's more easy to copy all %APPDATA%\Mozilla\Firefox\Profiles\ to ~/.mozilla before the first start of Firefox on the new GNU/Linux distribution. The new user will keep all this preferences. It's a good help to give this switch smooth.

And some users have a dual-boot with a profile share between windows and GNU/Linux, XDG Base Directory Specification could break i too.

I don't know if Microsoft have similar recommendation for windows
Comment 34 Stephan Sokolow 2013-01-05 12:36:29 PST
(In reply to vulcain from comment #33)
> I don't know if Microsoft have similar recommendation for windows

They do have the Local/Roaming split which could be roughly equated to putting everything in either $XDG_DATA_HOME or $XDG_CACHE_HOME like most Humble Bundle Linux game ports do.
Comment 35 Hugo Osvaldo Barrera 2013-01-05 12:43:42 PST
(In reply to vulcain from comment #33)
> The problem with XDG Base Directory Specification is that broken the copy of
> profile. 
> When we swift windows to Linux, it's more easy to copy all
> %APPDATA%\Mozilla\Firefox\Profiles\ to ~/.mozilla before the first start of
> Firefox on the new GNU/Linux distribution. The new user will keep all this
> preferences. It's a good help to give this switch smooth.
> 
> And some users have a dual-boot with a profile share between windows and
> GNU/Linux, XDG Base Directory Specification could break i too.
> 
> I don't know if Microsoft have similar recommendation for windows

Code will have to be written to migrate the current setting to their new location.

This code can be kept around, so when a firefox starts and finds stuff in .mozilla, it will move it to their proper location.
This will handle the scenario you propose just fine.
Comment 36 Hugo Osvaldo Barrera 2013-01-05 12:44:22 PST
(In reply to Stephan Sokolow from comment #34)
> (In reply to vulcain from comment #33)
> > I don't know if Microsoft have similar recommendation for windows
> 
> They do have the Local/Roaming split which could be roughly equated to
> putting everything in either $XDG_DATA_HOME or $XDG_CACHE_HOME like most
> Humble Bundle Linux game ports do.

Actually, cache and temporary files SHOULD NOT be in roaming, while user data and config SHOULD be.
Comment 37 Stephan Sokolow 2013-01-05 13:04:15 PST
(In reply to Hugo Osvaldo Barrera from comment #36)
> (In reply to Stephan Sokolow from comment #34)
> > (In reply to vulcain from comment #33)
> > > I don't know if Microsoft have similar recommendation for windows
> > 
> > They do have the Local/Roaming split which could be roughly equated to
> > putting everything in either $XDG_DATA_HOME or $XDG_CACHE_HOME like most
> > Humble Bundle Linux game ports do.
> 
> Actually, cache and temporary files SHOULD NOT be in roaming, while user
> data and config SHOULD be.

That's what I meant. Since I didn't say "respectively", I didn't think to pay attention to the order in which I listed the XDG variable names.
Comment 38 Rimas Kudelis 2013-01-05 13:24:53 PST
(In reply to vulcain from comment #33)
> The problem with XDG Base Directory Specification is that broken the copy of
> profile. 
> When we swift windows to Linux, it's more easy to copy all
> %APPDATA%\Mozilla\Firefox\Profiles\ to ~/.mozilla before the first start of
> Firefox on the new GNU/Linux distribution. The new user will keep all this
> preferences. It's a good help to give this switch smooth.
> 
> And some users have a dual-boot with a profile share between windows and
> GNU/Linux, XDG Base Directory Specification could break i too.

With Firefox Sync built in by default, and other sync engines available, is it really such a big problem?
Comment 39 Hugo Osvaldo Barrera 2013-01-05 13:53:12 PST
(In reply to Rimas Kudelis from comment #38)
> (In reply to vulcain from comment #33)
> > The problem with XDG Base Directory Specification is that broken the copy of
> > profile. 
> > When we swift windows to Linux, it's more easy to copy all
> > %APPDATA%\Mozilla\Firefox\Profiles\ to ~/.mozilla before the first start of
> > Firefox on the new GNU/Linux distribution. The new user will keep all this
> > preferences. It's a good help to give this switch smooth.
> > 
> > And some users have a dual-boot with a profile share between windows and
> > GNU/Linux, XDG Base Directory Specification could break i too.
> 
> With Firefox Sync built in by default, and other sync engines available, is
> it really such a big problem?

I agree. Worrying about shared profiles is a waste of time since sharing through sync should be the supported option.
Comment 40 Mike Hommey [:glandium] 2013-01-05 14:38:53 PST
Separating data in local/roaming profile is bug 239254
Comment 41 vulcain 2013-01-05 14:42:16 PST
(In reply to Rimas Kudelis from comment #38)
> 
> With Firefox Sync built in by default, and other sync engines available, is
> it really such a big problem?

When i help to switch i don't want to use a web tool just for get history, preference & Co one time. Copy profile or export/import bookmarks are more easly.

Sync is a good tool for an user with a lot PC or Android but not for an extemporaneous use.

After, some people who prefer use a partition to share Firefox and Thunderbird instead of an Internet’s server (aka the cloud). That their choice.

After, it's not a big problem, just a regression, i will use export/import (and need to launch windows only to do the export T_T )
Comment 42 Martin Stránský 2013-01-17 07:41:39 PST
Created attachment 703317 [details] [diff] [review]
Updated to latest trunk
Comment 43 Martin Stránský 2013-01-17 07:48:28 PST
Comment on attachment 703317 [details] [diff] [review]
Updated to latest trunk

Benjamin, can you check it please? When it gets in I'll update patch in Bug 239254 for that.
Comment 44 Leo Gaspard [:ekleog] 2013-01-17 10:15:08 PST
Comment on attachment 703317 [details] [diff] [review]
Updated to latest trunk

Review of attachment 703317 [details] [diff] [review]:
-----------------------------------------------------------------

Well... I'm probably of absolutely no use as I never really developped for firefox, but here is what I understood :
 * A bunch of new "atoms" is defined ;
 * A lot of new functions is defined ;
 * Some code is written if the argument atom is one of the new ones ;
 * Some other code is written in case PR_GetEnv("HOME") fails ; but just returns an error (BTW, wouldn't that belong to a second patch, separated, fixing another bug ?) ;

But where is the code that actually uses all of these new functions ? In which way does the patch solve the mentioned issue ?
Is the code re-dispatching the files (using the new "atoms") left to be implemented ?

Hoping I didn't tell nonsense,

Leo Gaspard
Comment 45 Mike Hommey [:glandium] 2013-01-21 09:10:03 PST
Comment on attachment 703317 [details] [diff] [review]
Updated to latest trunk

Review of attachment 703317 [details] [diff] [review]:
-----------------------------------------------------------------

Why do you need these to be exposed through the directory service with specific atoms?
Comment 46 Martin Stránský 2013-01-22 01:18:09 PST
(In reply to Mike Hommey [:glandium] from comment #45)
> Why do you need these to be exposed through the directory service with
> specific atoms?

Actually I don't need that, but isn't that a way how to do it? For instance for the patch in Bug 239254 - nsXREDirProvider::GetUserDataDirectoryHome. We have to use a hack there for now. And I guess another step is to move ~/.mozilla or ~/.thunderbird to ~/.config on linux.
Comment 47 Mike Hommey [:glandium] 2013-01-22 01:26:36 PST
(In reply to Martin Stránský from comment #46)
> (In reply to Mike Hommey [:glandium] from comment #45)
> > Why do you need these to be exposed through the directory service with
> > specific atoms?
> 
> Actually I don't need that, but isn't that a way how to do it? For instance
> for the patch in Bug 239254 - nsXREDirProvider::GetUserDataDirectoryHome. We
> have to use a hack there for now.

If there's only one place where each is going to be used, I'm not sure of the added value.

> And I guess another step is to move
> ~/.mozilla or ~/.thunderbird to ~/.config on linux.

I think we shouldn't move existing profiles, but only create new ones in the new location.
Comment 48 Martin Stránský 2013-01-22 01:48:46 PST
(In reply to Mike Hommey [:glandium] from comment #47)
> If there's only one place where each is going to be used, I'm not sure of
> the added value.

The added value is that the code will use a standard way how to get the directories and not some in-place hack. But yes, you're right, the .cache or .config dir is not used by mozilla yet. 

Actually it looks like there's something similar in GetUnixXDGUserDirectory() as a part of nsDirectoryService.cpp but for folders like Downloads, Music and so.

> > And I guess another step is to move
> > ~/.mozilla or ~/.thunderbird to ~/.config on linux.
> 
> I think we shouldn't move existing profiles, but only create new ones in the
> new location.

Sure, sounds reasonable.
Comment 49 sbastig 2013-01-22 05:36:19 PST
Most software I know, that added a compatibility patch for the XDG Config Spec also included some migration and compatibility code detect and move old profiles to the new location and in that process split up its contents.

Also please note, that it is not just about moving the whole profile to ~/.config (or $XDG_CONFIG_HOME) but also to separate the contents into CONFIG, CACHE and DATA parts, such that it becomes easier for example to clear the Mozilla cache (CACHE) or reset the preferences (CONFIG), without deleting the bookmarks or saved passwords (DATA).

If the profiles were not moved but only new ones are created in the new location, then Mozilla would require code to read from both the old and new locations. In the case the profiles are moved it is enough to keep the migration code long enough (e.g until the end of the ESR support period) and then remove it again.

P.S. Many thanks to the persons working on this bug, it is very very appreciated.
Comment 50 Mike Hommey [:glandium] 2013-01-22 05:45:33 PST
(In reply to sbastig from comment #49)
> Most software I know, that added a compatibility patch for the XDG Config
> Spec also included some migration and compatibility code detect and move old
> profiles to the new location and in that process split up its contents.
> 
> Also please note, that it is not just about moving the whole profile to
> ~/.config (or $XDG_CONFIG_HOME) but also to separate the contents into
> CONFIG, CACHE and DATA parts, such that it becomes easier for example to
> clear the Mozilla cache (CACHE) or reset the preferences (CONFIG), without
> deleting the bookmarks or saved passwords (DATA).

And you don't need to move the entire profile to do that. Again, bug 239254 does this for cache.

> If the profiles were not moved but only new ones are created in the new
> location, then Mozilla would require code to read from both the old and new
> locations.

No, there would only need to be code returning the old or the new location from the directory service.

Also note the profile contains a lot of things, and that there's no distinction between config and data at the moment, so moving things under .config would just move them for the sake of it, which is not helpful. Moving the caches is already a big step forward, but this is not what this bug is about.
Comment 51 Mike Hommey [:glandium] 2013-01-22 05:49:06 PST
Comment on attachment 703317 [details] [diff] [review]
Updated to latest trunk

I think we don't need these exposed through the directory service. It doesn't seem to me there's more need than to expand GetUnixXDGUserDirectory to return appropriate values for existing directory service atoms. That would help make the patch in bug 239254 feel less hackish.
Comment 52 Hugo Osvaldo Barrera 2013-01-22 05:49:41 PST
(In reply to Mike Hommey [:glandium] from comment #47)
> (In reply to Martin Stránský from comment #46)
> > (In reply to Mike Hommey [:glandium] from comment #45)
> > > Why do you need these to be exposed through the directory service with
> > > specific atoms?
> > 
> > Actually I don't need that, but isn't that a way how to do it? For instance
> > for the patch in Bug 239254 - nsXREDirProvider::GetUserDataDirectoryHome. We
> > have to use a hack there for now.
> 
> If there's only one place where each is going to be used, I'm not sure of
> the added value.
> 
> > And I guess another step is to move
> > ~/.mozilla or ~/.thunderbird to ~/.config on linux.
> 
> I think we shouldn't move existing profiles, but only create new ones in the
> new location.

I don't think that's a good idea.
If users know that firefox is XDG-Basedir compliant, they'll just happily backup ~/.config when needing to backup (for example, to install a different OS).

This will result in data loss for users who didn't know their profiles were still in an older location.

Also, keeping older profiles in an older location means a lot of code to handle both layouts. If we move to the XDG-Basedir directories, the old code can be deleted, and we can just keep the migration code, and the code that deals with the new locations.

Finally, I don't think firefox can claim to be XDG-Basedir compliant if *some* profiles are still managed elsewhere.
Comment 53 sbastig 2013-01-22 05:55:46 PST
I totally agree with Hugo in this point. Mozilla software should aim to be fully XDG-Basedir compliant and not leave behind any legacy folders.
Comment 54 Martin Stránský 2013-01-22 06:03:14 PST
Mike, if I understand correctly you propose to close this bug and get the XDG directories separately in each case (.config, .cache and so).
Comment 55 Mike Hommey [:glandium] 2013-01-22 06:11:42 PST
(In reply to Martin Stránský from comment #54)
> Mike, if I understand correctly you propose to close this bug and get the
> XDG directories separately in each case (.config, .cache and so).

We can keep this bug open as a tracker bug.
Comment 56 Mike Hommey [:glandium] 2013-01-22 06:14:13 PST
(In reply to Hugo Osvaldo Barrera from comment #52)
> I don't think that's a good idea.
> If users know that firefox is XDG-Basedir compliant, they'll just happily
> backup ~/.config when needing to backup (for example, to install a different
> OS).
> 
> This will result in data loss for users who didn't know their profiles were
> still in an older location.

Far from all applications are XDG complaint. Someone backuping .config only will have a lot of data loss other than their Firefox profile.

> Also, keeping older profiles in an older location means a lot of code to
> handle both layouts. If we move to the XDG-Basedir directories, the old code
> can be deleted, and we can just keep the migration code, and the code that
> deals with the new locations.

See comment 50.
Comment 57 Hugo Osvaldo Barrera 2013-01-22 06:19:36 PST
(In reply to Mike Hommey [:glandium] from comment #56)
> (In reply to Hugo Osvaldo Barrera from comment #52)
> > I don't think that's a good idea.
> > If users know that firefox is XDG-Basedir compliant, they'll just happily
> > backup ~/.config when needing to backup (for example, to install a different
> > OS).
> > 
> > This will result in data loss for users who didn't know their profiles were
> > still in an older location.
> 
> Far from all applications are XDG complaint. Someone backuping .config only
> will have a lot of data loss other than their Firefox profile.

If a user finds out firefox IS XDG-complaint, he'd ignore .firefox (assuming it was just old stuff), and backup .config; that's my point.

I've seen some software that copied it's data to XDG-Basedir locations, and left the old data where it was. When backing up, I'd ignore the old data, assuming it was deprecated.

> 
> > Also, keeping older profiles in an older location means a lot of code to
> > handle both layouts. If we move to the XDG-Basedir directories, the old code
> > can be deleted, and we can just keep the migration code, and the code that
> > deals with the new locations.
> 
> See comment 50.

Wrong, you won't need code to just read from the new (or old) location; the layouts inside each of is completely different.
Being XDG-Basedir compliant means some stuff is in ~/.cache, some stuff is in ~/.config, etc, NOT all together in a single directory. I'd also expect data to be organized differently inside each directory.
Comment 58 Benjamin Smedberg [:bsmedberg] 2013-01-22 06:32:10 PST
Because Firefox does not currently make any distinction between "data" and "config", and we really don't have plans to support that distinction in the future, I think that we should store the entire "roaming" profile as config, and the "local" profile as cache. We should not treat any Firefox things as data.

I agree that we should *not* move existing profiles.
Comment 59 Mike Hommey [:glandium] 2013-01-22 06:34:09 PST
(In reply to Hugo Osvaldo Barrera from comment #57)
> Wrong, you won't need code to just read from the new (or old) location; the
> layouts inside each of is completely different.
> Being XDG-Basedir compliant means some stuff is in ~/.cache, some stuff is
> in ~/.config, etc, NOT all together in a single directory. I'd also expect
> data to be organized differently inside each directory.

Things that would go in ~/.cache are currently in ~/.mozilla/firefox ;
Things that would go in ~/.config are currently in ~/.mozilla/firefox ;
etc.

You can's say "move the profile under ~/.config" and be done with it, obviously. You need to say: "this goes in ~/.config", "that goes in ~/.cache", etc.
But in the end, this and that both used to be in ~/.mozilla/firefox. There's nothing inherently difficult is supporting both locations. The difficulty is actually to put everything in the right place. And since there are many such things, and we add new ones regularly, you can be sure it won't happen in a snap of fingers, and even better, considering the windows and OSX code don't have distinction between config and data, you can be sure there will be mistakes, too.
Comment 60 Hugo Osvaldo Barrera 2013-01-22 06:40:37 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #58)
> Because Firefox does not currently make any distinction between "data" and
> "config", and we really don't have plans to support that distinction in the
> future, I think that we should store the entire "roaming" profile as config,
> and the "local" profile as cache. We should not treat any Firefox things as
> data.
> 

What are the "roaming" and "local" profiles?  As far as I can see, there's just a single profile ATM, stored in ~/.firefox/

I don't think configuration and cache should be stored together. Cache can grow a lot, while config is usually a few megabytes. Being unable to separate both while backing up makes backups grow a lot.

I also see no point in stuffing anything firefox-related into a single directory when we have proper locations for each type of file.
Comment 61 Mike Hommey [:glandium] 2013-01-22 06:46:54 PST
(In reply to Hugo Osvaldo Barrera from comment #60)
> What are the "roaming" and "local" profiles?  As far as I can see, there's
> just a single profile ATM, stored in ~/.firefox/

Windows and OSX code handle cache and other config/data separately. Linux code doesn't currently. That's bug 239254 (again).
Comment 62 sbastig 2013-01-22 07:08:18 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #58)
> Because Firefox does not currently make any distinction between "data" and
> "config", and we really don't have plans to support that distinction in the
> future, I think that we should store the entire "roaming" profile as config,
> and the "local" profile as cache. We should not treat any Firefox things as
> data.

If the firefox code "knows" what is config and what is data, then it should not be difficult to dedicate different locations for either of them on linux, but use the same one on Windows and Mac, for example on Windows both CONFIG and DATA would go into the same directory but could still have different subfolders (e.g AppData/RoamingProfile/firefox/{data,config}, where as on Linux they would go into completely separate folders (e.g. ~/.config/firefox/ and ~/.local/share/firefox). But if there is know plan to make such a distinction known to Firefox, then there is really no much to discuss in this bug. Just wait until the Caching  bug is closed and move/copy what ever is left to either ~/.config or ~/.local/share.

IMHO the interesting thing to discuss would be, why such a distinction is not planed. I think there is plenty of stuff that could be separated for example Passwords and Bookmarks (DATA) vs. Preferences and Extensions (CONFIG).

Of course the caching bug is a separate bug, so lets not discuss that again here.

@Hugo:
> What are the "roaming" and "local" profiles?  As far as I can see, there's
> just a single profile ATM, stored in ~/.firefox/
"Roaming" is a Windows Term und refers to the part of the users directory that can be copied to and from a server (for example in an active directory environment). Where as the "local" refers to a folder in the users directory that only exists in the local computer. So if applications want their configuration and data to be available on different computers, then they need to put that data into the "roaming" directory. Caching data is usually saved locally, to avaid coping potentially huge amounts of data to a server and back when the users logs on/off.
Comment 63 Benjamin Smedberg [:bsmedberg] 2013-01-22 07:21:28 PST
I have as module owner decided that we do not plan on trying to separate "config" and "data". The distinction is blurry to begin with: bookmarks are sure to be one mans data and another mans config, as are things like root certificates, certificate overrides, and other things. Because no other platform makes the distinction, coders working on the project are unlikely to know or care about the difference, leading to subtle XDG-only bugs.
Comment 64 sbastig 2013-01-22 07:34:59 PST
IMHO, a means to distinguish between data and config is to ask what happens if the data is deleted. For cache data it is obviously recreated automatically and the user might only see a short slowdown. For config data the user does not loose anything that he can't easily recreate, e.g. he can configure the preferences again, add certificates again etc.
Data is everything that if deleted is permanently lost (e.g. if the user does not remember his password or his bookmarked places, then he cannot recreate them). Extensions are a bit difficult, because they can be easily installed again, but the user needs to remember which modules he had previously installed. A solution would be to store the names of extensions in DATA and if config is deleted, then ask the user if he wants to install previously installed extensions.

Since on platforms where there is not distinction between config and data we could still put everything into a common parent folder but then create different subfolders, so I don't think the XDG-only bugs argument will be a big problem.
Comment 65 Hugo Osvaldo Barrera 2013-01-22 09:43:47 PST
(In reply to sbastig from comment #62)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #58)
> > Because Firefox does not currently make any distinction between "data" and
> > "config", and we really don't have plans to support that distinction in the
> > future, I think that we should store the entire "roaming" profile as config,
> > and the "local" profile as cache. We should not treat any Firefox things as
> > data.
> 
> If the firefox code "knows" what is config and what is data, then it should
> not be difficult to dedicate different locations for either of them on
> linux, but use the same one on Windows and Mac, for example on Windows both
> CONFIG and DATA would go into the same directory but could still have
> different subfolders (e.g AppData/RoamingProfile/firefox/{data,config},
> where as on Linux they would go into completely separate folders (e.g.
> ~/.config/firefox/ and ~/.local/share/firefox). But if there is know plan to
> make such a distinction known to Firefox, then there is really no much to
> discuss in this bug. Just wait until the Caching  bug is closed and
> move/copy what ever is left to either ~/.config or ~/.local/share.

Data and config are completely different things, that's why they each have their location.  Even if the cache is moved elsewhere, data and config need to be separated.

> 
> IMHO the interesting thing to discuss would be, why such a distinction is
> not planed. I think there is plenty of stuff that could be separated for
> example Passwords and Bookmarks (DATA) vs. Preferences and Extensions
> (CONFIG).
> 
> Of course the caching bug is a separate bug, so lets not discuss that again
> here.
> 
> @Hugo:
> > What are the "roaming" and "local" profiles?  As far as I can see, there's
> > just a single profile ATM, stored in ~/.firefox/
> "Roaming" is a Windows Term und refers to the part of the users directory
> that can be copied to and from a server (for example in an active directory
> environment). Where as the "local" refers to a folder in the users directory
> that only exists in the local computer. So if applications want their
> configuration and data to be available on different computers, then they
> need to put that data into the "roaming" directory. Caching data is usually
> saved locally, to avaid coping potentially huge amounts of data to a server
> and back when the users logs on/off.

I was familiar with roaming/local in windows NT enviroments; I though you were refering to something *nix-related so I got confused.

So why is it ok for firefox to conform to windows standard, but so much debate when it comes to implementing *nix standards?
Comment 66 Hugo Osvaldo Barrera 2013-01-28 08:19:55 PST
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #63)
> I have as module owner decided that we do not plan on trying to separate
> "config" and "data". The distinction is blurry to begin with: bookmarks are
> sure to be one mans data and another mans config, as are things like root
> certificates, certificate overrides, and other things. Because no other
> platform makes the distinction, coders working on the project are unlikely
> to know or care about the difference, leading to subtle XDG-only bugs.

The line is not blurry at all. Bookmarks are not configuration. You don't "configure" firefox with your bookmarks, they're clearly data.

I find it rather sad that this would be closed as WONTFIX - standard directories are respected for other OSs, so I think this is another example of firefox giving the linux community the "we don't care" response by not adjusting itself to XDG specifications.
Comment 67 Mike Hommey [:glandium] 2013-01-28 08:45:58 PST
(In reply to Hugo Osvaldo Barrera from comment #66)
> The line is not blurry at all. Bookmarks are not configuration. You don't
> "configure" firefox with your bookmarks, they're clearly data.

The line is so not blurry that epiphany puts bookmarks in .config/epiphany, not .local/share/epiphany.
Comment 68 sbastig 2013-01-28 08:57:48 PST
That does not make it more right, a bug should be filed for epiphany to correct that.
Comment 69 Benjamin Smedberg [:bsmedberg] 2013-01-28 09:05:52 PST
This is not a question of right and wrong, it is a question of engineering a cross-platform application. Because the distinction between data and config is not a concept on any of our other platforms, it is not something that engineers working on Firefox will think about. That means they will use the wrong directory and there will be subtle Linux-only bugs. (And the distinction is definitely still blurry).

Because of this engineering reality, I have made the decision that we will not support this distinction, and will store everything in one place. Given the current distinction, I believe that place will be "data".
Comment 70 Thomas Sisson 2013-05-10 12:55:55 PDT
My Two Cents

Microsoft does it's own thing. If software is to be run on a Microsoft OS, it conforms to Microsoft.

Google Chrome implements the XDG standard, but apparently does not distinguish between data and configuration. Google Chrome cache files are in ~/.cache/{Profile Name}/Cache and ~/.cache/{Profile Name}/MediaCache. All other Google Chrome user files are stored in ~/config/Google Chrome.

The cache location should be discussed here because it is part of the standard. When discussing the standard, we should include Firefox, SeaMonkey and Thunderbird. While incorporating the standard, we should do something about the legacy mozilla directory. 

I do think that some folders are quite obvious as data. Add-ons and plug-ins should be stored in the data directory. Additionally, GUI folders like chrome and other files that were historically in the Netscape application data directory but were later moved to the profile directory. This does not include configuration files such as prefs.js that should be in the configuration directory.

Mail that is stored on the computer should be in the data directory, while mail configuration should be in the configuration directory. Cached emails should be in the cache directory.

From reading the newest specification from http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html, it sounds like the most volatile date should be stored in the cache directory, the least volatile data that is set or changed by the application should be stored in the data directory (~/.local/share), and items configured by the user should be stored in the configuration directory.

It seems that data that can be synced and therefore roam from computer to computer is in the configuration directory. Data that is more specific to the current computer and operating system appear to belong in the data directory.

My Recommendation

If it is too difficult to separate application data from configuration data, that data could remain in the configuration data. However, I recommend at least separating plug-ins and add-ons.

The firefox directory should be removed from the mozilla directory. The mozilla directory may remain separately but be used only for data that can be used or ignored by other mozilla based applications.

Other gecko applications should still be able to read the mozilla directory for plug-ins.

Bookmarks could also be stored in the mozilla folder and made readable by other browser applications. The format could be HTML format or the new XBEL standard (http://pyxml.sourceforge.net/topics/xbel/docs/html/xbel.html). The actual format or availability of bookmarks in this directory can be up to those working on bookmarks for the Mozilla core.

Migration

The installation script must look for the existence of ~/.config/{Application Name}.
Comment 71 Stephan Sokolow 2013-05-10 13:07:57 PDT
(In reply to Thomas Sisson from comment #70)
> 
> Mail that is stored on the computer should be in the data directory, while
> mail configuration should be in the configuration directory. Cached emails
> should be in the cache directory.
> 

My one caution there would be that, for ease of backup, it'd probably be a good idea to consider all config required to access the data as data itself. Otherwise, it'd be like storing an MP3's raw data stream in one place and the frame headers required to decode it in another.

Lose those frame headers, and it's a ridiculous amount of trial-and-error to restore your backups.

> 
> It seems that data that can be synced and therefore roam from computer to
> computer is in the configuration directory. Data that is more specific to
> the current computer and operating system appear to belong in the data
> directory.
> 

Where did you get that impression? Everything I've read and heard tells me it was under the impression it was the other way around.

(Configuration data being stuff that is easier to replace and more machine-specific. Data being less machine-specific and harder to replace.)

Think of it in the context of something like Thunderbird address books vs. something like what SMTP server a given machine uses or some saved window geometry. 

Your address book is at least as important and system-agnostic as a LibreOffice document but you don't access it through an open dialog, so it goes under data where tools will prioritize backing it up.

Your configuration, like what SMTP server you use, may be different on different PCs and, while it'll be a pain to re-enter, it's not the end of the world if you lose it.

> If it is too difficult to separate application data from configuration data,
> that data could remain in the configuration data. However, I recommend at
> least separating plug-ins and add-ons.

The only way I can see that making sense is if you consider plugins and addons to be "configuration". Otherwise, what's there to separate when things like bookmarks belong under "data"?
Comment 72 Benjamin Smedberg [:bsmedberg] 2013-05-10 13:12:29 PDT
We are not going to separate config and data. That discussion is closed, and further discussion of it is unwelcome in this bug. I have delegated to glandium the decision about whether we store our profile data in the config or data XDG subtree.
Comment 73 Hugo Osvaldo Barrera 2013-05-10 13:19:03 PDT
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #72)
> We are not going to separate config and data. That discussion is closed, and
> further discussion of it is unwelcome in this bug. I have delegated to
> glandium the decision about whether we store our profile data in the config
> or data XDG subtree.

I remain confused. Does Mozilla support GNU/Linux, or doesn't it?

It seems that you put attention into the fact that the code builds, and package it, but you don't adapt to the OS's standard. (Though you *do* for other Operating Systems).

Are you slowly dropping support for GNU/Linux? Because you either support, or don't, it confuses users if you say you do, and then ship half-ported software.
Comment 74 Thomas Sisson 2013-05-10 13:28:15 PDT
Migration (continued)

Sorry I'm so long-winded.

The installation script would also look for the existence of ~/.mozilla/{Application Name} or ~/.{Application Name} if the new profile location is not found. If no profiles are found, the profile directory would be created in the XDG compliant location. Migration would be similar to the old Netscape migration. The post-installation would offer the user the option to keep the old profile(s) or delete them when finished. For deletion, a warning would be made that this cannot be undone and that this change is not backwards compatible for previous versions. For the option to keep the the old profile, the user is told that any new changes will not show up in the old profile.

The option to migrate and delete old profiles should be made available through multiple updates but eventually be removed. At that time download pages would explain that old profiles would not be used. Any users who have not updated or upgraded the application would be able to find information on how to migrate old profiles.

Someone could choose to write an add-on that would migrate old profiles at any time.

When this is implemented, it provides an opportunity to implement any major changes that would not be compatible with previous versions of the application.
Comment 75 Stephan Sokolow 2013-05-10 13:36:17 PDT
(In reply to Hugo Osvaldo Barrera from comment #73)
> 
> I remain confused. Does Mozilla support GNU/Linux, or doesn't it?
> 
> It seems that you put attention into the fact that the code builds, and
> package it, but you don't adapt to the OS's standard. (Though you *do* for
> other Operating Systems).
> 
> Are you slowly dropping support for GNU/Linux? Because you either support,
> or don't, it confuses users if you say you do, and then ship half-ported
> software.

Please don't use those "you're either with us or against us" tactics. They poison the discourse and, if people did rise to your bait, they'd be more likely to drop Linux support to spite you than do what you want.

As a Linux user, I honestly don't care that much. The config-data divide is somewhat orthogonal to how a browser does things and, given how much of Firefox's profile is data, splitting out the small parts that are config would probably harm more than it helps.

As long as Firefox properly separates out content meant for XDG_CACHE_HOME and XDG_RUNTIME_DIR (user-specific locks and sockets), I have no problem with profiles just being plopped into XDG_DATA_HOME.

My main concerns are:

1. Backup tools should be able to offer sane defaults for things like excluding caches and, even if I do configure manually, I should have to babysit the config file as little as possible as I install and remove applications.

2. If an application gets wedged and concludes that another copy still exists when it doesn't, there should be one standard place I look for stale locks and sockets.

3. There shouldn't be 50 million different folders in my homedir when I choose to show hidden files.
Comment 76 Thomas Sisson 2013-05-10 13:49:21 PDT
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #72)
> We are not going to separate config and data. That discussion is closed, and
> further discussion of it is unwelcome in this bug. I have delegated to
> glandium the decision about whether we store our profile data in the config
> or data XDG subtree.

I was only offering "My Two Cents" as my opinion. I had not realized such discussion was deemed closed. I further acknowledge the difficulty of separating the two and suggested the config XDG subtree.

I don't know who you are, what you contribute to the project, or what status you hold in relation to this bug, so I say this with trepidation and as much respect as possible intended. If you don't wish to hear about what people think about which is which kind of data, couldn't you check the box labeled "Ignore Bug Mail?" I do see your point though, and leave that to glandium for implementation.
Comment 77 Thomas Sisson 2013-05-10 14:01:32 PDT
(In reply to Stephan Sokolow from comment #71)
> (In reply to Thomas Sisson from comment #70)
> > 
> > Mail that is stored on the computer should be in the data directory, while
> > mail configuration should be in the configuration directory. Cached emails
> > should be in the cache directory.
> > 
> 
> My one caution there would be that, for ease of backup, it'd probably be a
> good idea to consider all config required to access the data as data itself.
> Otherwise, it'd be like storing an MP3's raw data stream in one place and
> the frame headers required to decode it in another.
> 
> Lose those frame headers, and it's a ridiculous amount of trial-and-error to
> restore your backups.
> 
> > 
> > It seems that data that can be synced and therefore roam from computer to
> > computer is in the configuration directory. Data that is more specific to
> > the current computer and operating system appear to belong in the data
> > directory.
> > 
> 
> Where did you get that impression? Everything I've read and heard tells me
> it was under the impression it was the other way around.
> 
> (Configuration data being stuff that is easier to replace and more
> machine-specific. Data being less machine-specific and harder to replace.)
> 
> Think of it in the context of something like Thunderbird address books vs.
> something like what SMTP server a given machine uses or some saved window
> geometry. 
> 
> Your address book is at least as important and system-agnostic as a
> LibreOffice document but you don't access it through an open dialog, so it
> goes under data where tools will prioritize backing it up.
> 
> Your configuration, like what SMTP server you use, may be different on
> different PCs and, while it'll be a pain to re-enter, it's not the end of
> the world if you lose it.
> 
> > If it is too difficult to separate application data from configuration data,
> > that data could remain in the configuration data. However, I recommend at
> > least separating plug-ins and add-ons.
> 
> The only way I can see that making sense is if you consider plugins and
> addons to be "configuration". Otherwise, what's there to separate when
> things like bookmarks belong under "data"?

That demonstrates the confusion in separating into config and data and differences in specification and implementation which is why, despite my comments, the discussion is closed.

See Benjamin Smedberg [:bsmedberg] 2013-05-10 13:12:29 PDT [Comment 72] https://bugzilla.mozilla.org/show_bug.cgi?id=259356#c72.
Comment 78 Hugo Osvaldo Barrera 2013-05-10 14:11:44 PDT
(In reply to Stephan Sokolow from comment #75)
> (In reply to Hugo Osvaldo Barrera from comment #73)
> > 
> > I remain confused. Does Mozilla support GNU/Linux, or doesn't it?
> > 
> > It seems that you put attention into the fact that the code builds, and
> > package it, but you don't adapt to the OS's standard. (Though you *do* for
> > other Operating Systems).
> > 
> > Are you slowly dropping support for GNU/Linux? Because you either support,
> > or don't, it confuses users if you say you do, and then ship half-ported
> > software.
> 
> Please don't use those "you're either with us or against us" tactics. They
> poison the discourse and, if people did rise to your bait, they'd be more
> likely to drop Linux support to spite you than do what you want.
>

That might not be a bad thing. Mozilla is keeping firefox-for-linux almost frozen. Linux specific issues keep getting rejected, and I've seen plenty of builds with just windows-specific enhancements.

At least if Mozilla compeltely dropped Firefox for *nix, some other foundation would have the motivation to pick it up and really maintain it.

As-is, it just stagnates. All you get is security updates.
And no, a single person can't just branch it; you need something with way larger resources.
Comment 79 Stephan Sokolow 2013-05-10 14:26:44 PDT
(In reply to Hugo Osvaldo Barrera from comment #78)
> That might not be a bad thing. Mozilla is keeping firefox-for-linux almost
> frozen. Linux specific issues keep getting rejected, and I've seen plenty of
> builds with just windows-specific enhancements.

Please cite sources. So far, the only thing which comes to mind which might explain your claim that it's frozen is that Mozilla isn't bending over backward to integrate with all the unproven ideas the Ubuntu and GNOME UI teams are hopping on.

Personally, I'd call that "taking a cautious approach to avoid wasting manpower".
Comment 80 Justin Dolske [:Dolske] 2013-05-10 16:23:46 PDT
I'm restricting further comments on this bug. Bugzilla isn't intended as a debate forum. Benjamin's the module owner in this area, and he's already asked glandium to look into it. Both are longtime Mozilla contributors, and glandium's commitment to Linux is beyond reproach (http://glandium.org/about/). No further flames, please.

[Comments are restricted to users with the editbugs privilege -- with privilege comes responsibility, so please consider carefully before commenting if you are able.]
Comment 81 Mike Hommey [:glandium] 2013-05-10 22:35:53 PDT
Just a clarification, after such a comment flood, the status of this bug is that it's waiting for a new patch taking into account comment 51. I'll happily review such patch.
Comment 82 Martin Stránský 2013-05-13 06:30:50 PDT
Mike, which (existing ones?) directory service atoms would you like to utilize by GetUnixXDGUserDirectory()? Bug 239254 uses XDG_CACHE_HOME or $HOME/.cache only.
Comment 83 Mike Hommey [:glandium] 2013-05-13 07:07:14 PDT
(In reply to Martin Stránský from comment #82)
> Mike, which (existing ones?) directory service atoms would you like to
> utilize by GetUnixXDGUserDirectory()? Bug 239254 uses XDG_CACHE_HOME or
> $HOME/.cache only.

The sXDG* atoms and NS_UNIX_XDG_* strings are pretty much useless. Just expose the "right" value from nsXREDirProvider::GetUserDataDirectory. Adjustments will need to be done to e.g. nsXREDirProvider::AppendSysUserExtensionPath, and maybe others. That still leaves the problem of data migration, which i still think we'd just better avoid entirely, especially with all the things that keep file paths in preferences and whatnot. The reset feature from about:support could probably be made to force the switch.
Comment 84 [:Aleksej] 2013-10-08 10:05:26 PDT
*** Bug 923923 has been marked as a duplicate of this bug. ***
Comment 85 Benjamin Smedberg [:bsmedberg] 2015-02-02 13:42:45 PST
*** Bug 1128692 has been marked as a duplicate of this bug. ***
Comment 86 Shmerl 2015-08-22 20:34:11 PDT
Is there any progress with this? So far Firefox still uses $HOME/.mozilla and doesn't conform to XDG base directory specification.
Comment 87 Benjamin Smedberg [:bsmedberg] 2015-08-24 10:10:20 PDT
There is no progress on this bug. It is assigned to nobody and is not a priority for the team.
Comment 88 Tom Oehser 2016-05-20 06:19:41 PDT
I use NFS /export/home/tom between multiple machines.
XDG means that I can have more than one machine logged in.
With Firefox, I can "pick the profile" at launch.
With Thunderbird, it seems I just "can't launch it", if it is open on another host sharing home.
???

Note You need to log in before you can comment on or make changes to this bug.