https://linuxiac.com/mozilla-resolves-21-year-old-bug-adds-full-xdg-directory-support/
Firefox 147 adds support for the XDG Base Directory Specification, ending a 21-year wait and aligning the browser's Linux file storage with modern standards.
The upcoming Firefox 147 will introduce a long-requested change for Linux users by finally adopting the XDG Base Directory Specification, closing a bug that has been open for more than 21 years.
The update modernizes how the browser stores files on Linux systems and aligns its behavior with that of most desktop applications, which have been doing so for years. Here's what I'm talking about.
Until now, Firefox placed nearly all of its user files—settings, profiles, data, and cache—inside a single folder called ~/.mozilla in the user's home directory. This approach worked, but it also contributed to the familiar clutter many Linux users see when applications each create their own hidden folders.
At the same time, the XDG Base Directory Specification is a widely used standard that aims to organize those files cleanly. Instead of placing everything directly in a single directory, applications are encouraged to use three dedicated locations: one for configuration files, one for application data, and one for cache files. These are typically found under ~/.config, ~/.local/share, and ~/.cache.
Starting with Firefox 147, newly created profiles on Linux will follow this structure. Configuration files, long-term data, and temporary cache files will now be stored in their proper locations.
It's important to note that this doesn't affect existing users immediately: if a legacy ~/.mozilla folder already exists, Firefox keeps using it to avoid breaking profiles. But for anyone installing Firefox fresh or creating new profiles, the browser will behave like other modern Linux applications.
As I said in the beginning, the change also marks the end of one of the browser's longest-standing issues. Believe it or not, bug 259356 was first reported in 2003, and the request to support XDG directories has resurfaced repeatedly among Linux users and distributions over the years.
It is expected that this change will finally simplify file management, reduce home-folder clutter, and, most importantly, align the browser with the expectations of today's Linux environments.
(Score: 4, Insightful) by Unixnut on Wednesday November 26, @08:24PM (5 children)
So mozilla went from one simple single location for everything related to the program, to having it spread over three different locations which are shared with other programs, and this is progress? It seems to just make it harder to keep a clean separation between different programs and keeping it simple when it comes to knowing where to look for the programs user configuration.
Its the same nonsense Chrome does, forcing me to dig around my homedir to find all the nooks and crannies where it has deposited some configuration or state file, rather than just having to look in a single path (and issue I had to deal with recently to debug some chrome issues I was having).
From my point of view mozilla would have been better off not fixing this "bug" in the first place, but then firefox has been circling the drain for years now.
(Score: 4, Informative) by tekk on Wednesday November 26, @09:02PM (2 children)
To be clear: the standard doesn't say to dump all of your files in ~/.config (for example) it says to dump them in ~/.config/mozilla. The main benefit of the system is that for example I can tell my backup scripts to just back up ~/.config and it'll capture it all, as opposed to ~/.emacs.d (don't forget ~/.emacs if you haven't migrated to init.el), ~/.muttrc, ~/.mozilla, ~/.purple, ~/.mplayer, ~/.links, and ~/.icewm, to pick a few from my own home directory.
(Score: 2) by aafcac on Saturday November 29, @09:16PM
I wish there would be better tools for managing the cruft that collects in the home directory. Even just banning stupid directory names like .muttrc that are the appname, or substring of the app name with a suffix added to the end of it would make it so much easier to identify to which program the folder belongs. I've got this random .p2 directory in my home directory that apparently belongs to Eclipse, but there's no way of knowing that without going into the directory and guessing based on the stuff I find. At least with .cache you can generally just delete anything in there without much penalty.
(Score: 2) by driverless on Sunday November 30, @01:51AM
Does it? From my reading:
seems like an invitation to create a giant clusterfuck in $HOME/.config. I assume somewhere in the tl;dr pile of text it says something about subdirectories, but I can't immediately see it.
Also, how does this mesh with the bazillion other ways to do it, e.g. FHS' /etc/opt, $HOME/.$appname, and others? Just looking at my local FS and there's no $HOME/.config present, just a .local and a .cache, so it seems like a lot of people haven't got the memo about XDG.
(Score: 4, Interesting) by namefags_are_jerks on Wednesday November 26, @09:06PM
Yep. "tar cvf moz.tar .mozilla" has always been done here before a upgrade, lest there's a repeat of the lossage that killed critical extensions and such with past group-think.
(Score: 3, Interesting) by aafcac on Saturday November 29, @09:27PM
From the looks of it, the standard itself is actually pretty sensible. XDG itself just gives you a place for configuration files related to the user, a place for user specific cache files, a place for user specific data and a user specific place for state information.
The bigger issue that I can't tell if XDG addresses is Mozilla's asinine practice of using Mozilla as the name for some of their directories. Hopefully, that will be dropped as part of this as it does make it a bit harder to identify whether the folder belongs to Firefox or one of the other Mozilla projects and more importantly whether or not you can just nuke it after uninstalling Firefox.
And much of the issues related to figuring out what belongs to what and dealing with it could be addressed by just having a short text file indicating the ownership of the directory, or better yet, just requiring that such folders be named based on the name of the program that installed it. Most of them seem to already do that, but I have a few folders from over time that are named stupid things like .p2 and .mozilla.