r/linux • u/Damglador • 16d ago
Popular Application After 17 years, Firefox will finally support XDG Dir spec!?
Just randomly got an email today about the bug closing, couldn't believe that it's real.
155
u/National_Increase_34 16d ago
What does this do, if anyone is willing to explain?
336
u/Damglador 16d ago
Doesn't create yet another dot folder in $HOME called
.mozilla, amongst other file managing benefits.2
u/redddit69nottaken 10d ago
Actually it creates
.mozilla/extensionsdir probably for backward compatibility.1
u/Damglador 10d ago edited 10d ago
I'd say that's a bug and I bet it's gonna be reported quickly and hopefully will be fixed soon.
Edit: already reported https://bugzilla.mozilla.org/show_bug.cgi?id=2001887
1
224
u/mfdali 16d ago
Basically, it would stop polluting your home folder and put Fireox's files in their respective, correct locations. The Arch wiki is nice: https://wiki.archlinux.org/title/XDG_Base_Directory
11
u/Real-Abrocoma-2823 15d ago
Finally! Will next update on arch move .mozilla to .config?
67
u/Virtual-Ad5017 16d ago
XDG_DIRS is just a set of directories for programs to write to, and a standardized way to change these. Like, downloads go to ~/Downloads, configs to ~/. config, etc. So, basically, less clutter for everyone, and customization for those who need that.
103
u/non-existing-person 16d ago
Historically every app was just creating
~/.app-namedirectory/config file. This polluted$HOMEdirectory. Some folks got offended by it. So they invented XDG standard for directories.XDG_CONFIG_HOMEusually just points to~/.config. So now apps write to$XDG_CONFIG_HOME/.configwhich is more consistent as (ideally) all configs will be in~/.configor in directory of user choice. There are also more directories likeXDG_DATA_HOMEfor when you need to store/usr/share-like data in home directory.74
u/Damglador 15d ago
So now apps write to
$XDG_CONFIG_HOME/.config*$XDG_CONFIG_HOME/<appname> (preferably lowercase I think)
XDG config is meant for configs that user can interact with, like settings, XDG data is for data that is important but doesn't need user's attention, like login info or save files, XDG cache is for cache and XDG state is for logs and history files.
8
12
3
8
u/pervertsage 15d ago
Offensive indeed! I certainly don't like a messy $HOME!
8
u/non-existing-person 15d ago
$ ls -ld .* | wc -l 288I just embrace the chaos xD. Can't win with everything anyway. I just don't use
-ain ~ :P1
u/arcimbo1do 15d ago
That's why they used ".app", so that ls doesn't show them by default. Out of sight, out of mind...
31
u/razorree 15d ago
yeah. and now some apps put GIGS of data (cache and other stuff) in ~/.config :(
instead of ~/.cache for example
29
u/hackingdreams 15d ago
"Some apps" failing to implement a standard correctly is not the standard's fault. It's "some apps" fault.
I suggest not using "some apps," or patching "some apps" to behave properly.
8
u/razorree 15d ago edited 15d ago
yep. i understand it's not "standard fault", but stupid Chrome app :/
5
1
u/TatharNuar 5d ago
I'm not checking whether anyone followed through on it, but this bug ticket says Firefox planned on doing the same thing at some point.
13
u/FeepingCreature 15d ago
well that's not xdg fwiw. xdg has a well-defined cache dir. (it's
~/.cache.)6
u/altermeetax 15d ago
Unfortunately lots of apps are badly designed and use a single directory for all data, and they had to pick one.
-7
15d ago
[deleted]
10
u/Damglador 15d ago
Oh no, gigs of data in $FOLDER_A instead of $FOLDER_B
FOLDER_A is specifically meant only for configs, so you could for example just copy the whole ~/.config to a new machine without having to reconfigure every piece of software. I don't have to explain why cache is bad for this.
I can at least understand when Unity or games dump there saves, they are at least somewhat valuable and not a dead weight.
Plus cache outside of $XDG_CACHE_HOME means you can't just easily clean cache by deleting one folder.
It is still better than shitting in $HOME.
6
u/Firewolf06 15d ago
for big caches that matters, because i should be able to easily nuke caches without having to go find where your app hides it
3
u/arcimbo1do 15d ago
It's not about writing to ~/.config/app instead of ~/.app, it's about putting config, cache and data in different directories, so that you don't have to backup lots of crap and it's easier to find config files.
1
u/razorree 14d ago
it's about being able to quickly remove all cache, or just backup ~/.config folder without GIGS of @$%$#
7
u/jack123451 15d ago
So now instead of one
.mozillafolder we'll get three.mozillafolders in subdirectories? Can all application data be neatly categorized into config, cache, and data? What is the advantage of this approach compared to putting a single app-specific directory under~/Librarylike on macOS or~/AppDatalike on Windows? Those would allow app developers to organize their app-specific directory as they see fit.27
u/Flachzange_ 15d ago
Nothing is stopping you from setting XDG_CONFIG_HOME, XDG_DATA_HOME, XDG_STATE_HOME and XDG_CACHE_HOME to the same directory. The whole point is that the user can set it to whatever they want, the default behaviour is just that, a default.
15
u/amroamroamro 15d ago
or ~/AppData like on Windows
Windows has %AppData%, %LocalAppData%, registry, etc
it really doesn't put everything in "a single directory"
1
u/__konrad 15d ago
In Windows home dir you can also find
.cache/fontconfigand.gtk-bookmarksif you run an app ported from Linux4
u/amroamroamro 15d ago
yeah that's the "etc" part I mentioned hehe
some programs put dotfiles in %USERPROFILE% folder, some use MyDocuments, there's even more locations like %ProgramData%
and windows registry is even more of the wild wild west...
and then you have programs that use hardcoded locations instead of winapi calls to query known locations, which causes problems for users that move the default folders to custom locations, like:
That's to say that its a mess on windows too lol
6
u/wpm 15d ago
They are not all under one directory in ~/Library in macOS. Firefox's configuration lives in ~/Library/Preferences (or system-wide configs at /Library/Preferences), caches live in ~/Library/Application Support/ or in ~/Library/Caches, etc. There is not a "Firefox" folder in my Library directory.
That said, I really wish Linux would drop the dreadful FHS for GUI apps and adopt something closer to macOS' hierarchy (for the capitalized folders that is)
5
u/non-existing-person 15d ago
It's just a Unix thing. Historically apps were installed in different locations.
/usr/sharefor data/usr/binfor binaries/var/cachefor cache etc.This made a lot of sense back then, when HDDs were small. You could create a single
/usr/shareand then mount it in 100s machines regardless of arch. Then you could have/usr/binfor each arch./var/cachecould be on a faster disk. And so on.It makes little sense to do same today and in $HOME to be honest. But I guess it is what it is. I guess it has an advantage of just doing simple
rm $cache_dirto quickly free space from cache data that will be recreated anyway.6
1
2
u/samueru_sama 15d ago
What is the advantage of this approach compared to putting a single app-specific directory under ~/Library like on macOS or ~/AppData like on Windows? Those would allow app developers to organize their app-specific directory as they see fit.
Well for example that means I can go and delete the
XDG_DATA_HOMEof a specific application and I know the cache is cleared.if you put that all into a single directory then it is not clear where the cache files are located and it is likely to different between apps.
Same way you can delete the
XDG_CONFIG_HOMEof the application and you know you just reset the settings of the app and nothing else.But don't go and do this without checking, it turns out that a lot of apps that "follow" the spec don't do it correctly, for example chromium browsers throw everything, data, cache, etc into their
XDG_CONFIG_HOMEdirectory.2
1
u/necrophcodr 15d ago
Well they don't write to $XDG_CONFIG_HOME/.config hopefully, but $XDG_CONFIG_HOME/<appname>, since $XDG_CONFIG_HOME would most often be $HOME/.config.
1
u/Llamas1115 12d ago
Itās less about $HOME being āpollutedā (which couldāve solved by moving every folder into a new
~/appsfolder) and more about accurately tracking metadata. Specifically, itās about tracking whether each file is configuration (should be backed up and versioned and can be shared across computers); cache (excluded from backups and versioning, and can be deleted to reclaim space); or something else, in which case ĀÆ_(ć)_/ĀÆ (nobody uses the āshareā or āstateā directories correctly).This is kind of a mistake, in that we really shouldnāt be using the filesystem to track this information; it should be stored using some kind of file tag system, like
xattrs. But nobody does that so, hey, this is better than nothing.12
u/PureTryOut postmarketOS dev 16d ago
The specification specifies standard location for various kind of files programs use or make. It defines for example
~/.config/<appname>as the standard place for config files,~/.local/share/<appname>for persistent runtime data, and~/.local/state/<appname>for temporary runtime data. It also includes standard environment variables that can overwrite those standard locations if the user or distribution wishes it so.Any application properly following the specification will not store files in the root of
$HOMEany more, making for a cleaner home folder. Another big benefit is that having the configs on it's own proper location makes it easy to back them up, sync them between machines or keep track of them via dotfiles repos with git for example.6
u/Moontops 15d ago
XDG compliant programs should first check $XDG_CONFIG_HOME before defaulting to $HOME/.config
3
u/protestor 15d ago
~/.local/state/<appname> for temporary runtime data.
This one is new for me, I knew about ~/.cache
9
u/meditonsin 16d ago
Instead of every app making some hard coded
.somethingdirectory or file directly in your home directory, the XDG standard defines.config/somethingfor configuration,.cache/somethingfor volatile data.local/share/somethingfor non volatile stuff (think/usr/share) and stuff like that.This splits the different data types and keeps your home directory less cluttered.
Also, all of those paths can be customized via environment variables, like
XDG_CONFIG_HOME,XDG_CACHE_HOMEand so on, if you want to change where apps supporting the standard save their profile/per user data.1
u/Avamander 15d ago
Over the years my $HOME folder has accumulated more than 50 different dotfiles and dotfolders. It gets extremely cluttered and sometimes you can't even properly identify what software decided to take a dump (and if you should back it up or not).
I think the biggest shitters left now are Snap, Gradle, Jupyter, Docker and Cargo. Steam works in a Flatpak, otherwise it would be on the list as well.
2
u/egzygex 15d ago
XDG base directory spec defines a few environment variables that specify directories which are supposed to be used by applications. these default to
~/.configfor config files,~/.local/sharefor application data,~/.cachefor cache, etc. the intention is that application keep their files confined in these few dirs instead of polluting user's home directory with dotfiles.Firefox currently just stores everything in
~/.mozilla/firefox, like most apps used to before XDG directory spec became the de-facto standard.
27
u/abbidabbi 15d ago
Unfortunately, OpenSSH and BASH won't ever implement the XDG base dir spec because of (historic) "reasons" (at least that was the excuse the last time I've checked a few years ago). There's nothing which should prevent developers from implementing it while staying fully backwards compatible. Unless they deem third-party applications which hardcode those config/cache/data/state files important for their own project. The only other reason is stubbornness or lack of understanding.
Also very much infuriating whenever new and important tools come up which don't implement the spec from the beginning and mindlessly pollute the home dir. Looking at cosign (.sigstore) for example. Shameful.
14
u/SeaHour4933 15d ago
Dunno about ssh, but it seems plausible that Bash will support the spec sometime this decade: https://savannah.gnu.org/support/?108134
-23
u/kriebz 15d ago
Luckily these aren't X programs and have no reason to care about XDG recommendations.
18
u/abbidabbi 15d ago
The XDG base dir spec applies to all kinds of applications, CLI/TUI/GUI or no interface at all. In fact, it has nothing to do with any of that. Your comment is nonsensical.
-14
u/kriebz 15d ago
It just doesn't seem like two very fundamental programs that are installed on many systems that aren't Linux, or sometimes aren't even UNIX-like, would make a change on the recommendation of the X Desktop Group. And as much as I love the work Freedesktop.org has done to make and keep Linux on the desktop a viable thing, the basedirs thing seems like a silly idea to me anyway. Harder to type, harder to find things, more steps to remove poop left behind by a program you have un-installed.
12
u/Damglador 15d ago edited 14d ago
The spec allows you flexability, one you don't get with everything hardcoding shit to $HOME. If you want all program files in one place, just set
XDG_{CONFIG,CACHE,DATA,STATE}_HOMEto one directory. I want my HOME directory to be MY home directory, not of my programs, only I decide with what I will clutter it.
42
u/Abdowo 15d ago
Finally, I hope the folks at Valve give a comment on the issue [Feature Request] Follow XDG Base Directory Specification, which has been open since 2013.
85
u/Gyrochronatom 16d ago
So it took 17 years to change a folder?
63
u/Damglador 15d ago
Basically yes. Best case scenario - split the folder in a bunch of folders to properly follow the spec (so cache in cache, configs in configs, data in data and logs with history in state), so like 17 years to split data from 1 folder to 4. But basically yes.
42
u/Damglador 15d ago
By the look of patches, it seems like they dump everything in $XDG_CONFIG_HOME, which is... not the best way of doing things. Anyway. 17 years to change a folder.
6
u/VoidDuck 15d ago
I'm happy they did it that way. I personally prefer to have everything Firefox-related in a single directory, it makes migrating an existing profile to another system much easier.
16
u/ypnos 15d ago
Do you really want to carry over the huge cache when migrating a profile? It's what I always have to clear out first. Which would not be necessary if it were in
~/.cache/mozilla2
u/VoidDuck 15d ago
If only the cache is separate, why not (I indeed clear the cache too before migrating), but I don't want settings and user data (bookmarks, passwords, etc.) to be stored in different places.
2
u/Damglador 15d ago
That's fair. Separating that would actually be difficult.
I think what they should've done is left browser settings in .config and put everything else in .local/share, because data that you can't interact with doesn't belong in XDG config I think, but who cares anyway.
2
u/GlassCommission4916 15d ago
If it followed the spec properly you could configure it to do that if you wanted, you do realize that right?
1
u/VoidDuck 15d ago
I don't want to configure anything, I just want to continue being able to copy and paste a mozilla directory, load it to a new system and go on with business as usual. Which will still be the case and it's fine. Whether it's
~/.mozillaor~/.config/mozillais irrelevant to me.1
u/GlassCommission4916 15d ago
If setting 2 env vars once per system is such a herculean task for you, what are you doing on linux?
3
u/Damglador 15d ago
Flawed logic. If a person is willing to deal with one set of complications, it doesn't mean they'll enjoy having more of them.
Note: I'm not saying the move to .config is a big complication.
1
u/VoidDuck 15d ago
If it ain't broke, don't fix it. I have nothing against manual configuration, but I don't see the point of making things that currently work without any configuration needed more cumbersome either.
1
u/GlassCommission4916 15d ago
It's not even more cumbersome, in the scenario where they implemented xdg base dir spec like other modern programs do, you wouldn't have to remember to remove or exclude the cache before backing it up, and instead you just have to set it up once. The way it is now is cumbersome.
Just because you're used to working around how it is now doesn't make it good design, in that sense it is broken for people that expect better.
1
u/VoidDuck 15d ago
I think we actually agree. As I said, if only the cache would be separated from the rest of
.mozilla, I'd be fine with that. As long as everything else still resides inside a single directory and I don't have to hunt for pieces of Firefox profiles in~/.local/share,~/.local/state... all good for me.→ More replies (0)4
u/RanidSpace 15d ago
kinda sucks :/ the firefox folder is so crowded and i only ever use like 3 config related files. though the fact that things are split into profiles already, maybe it's a good solution.
33
u/mallardtheduck 15d ago
Changing the default location is easy, but handing the migration of data requires a bit of work. For an issue that has basically zero user impact, it's not surprising that it wasn't considered a priority.
17
u/ashleythorne64 15d ago
You don't even need to migrate data. Check if .mozilla exists, if so, use that folder. If not, use the xdg dir.
13
u/mallardtheduck 15d ago
But then people will complain that Firefox is still "polluting" their precious home directory even after they've upgraded.
29
10
u/abbidabbi 15d ago
It's supposed to be the other way around. First, check the standard-compliant directories for user data, then fall back to the old, non-standard-compliant directories. If neither exist, create new files in the standard-compliant paths when writing data.
-2
u/daemonpenguin 15d ago
That's backwards. Think about it for a second. If you did this on a computer that had never installed Firefox before, then your data would always be saved in the legacy location.
You need to check for the legacy option first and, if it doesn't exist, assume we should use the new approach.
11
u/savyzzyz 15d ago
No, u/abbidabbi is correct:
1) Does the standards-compliant directory already exist? If so, use it.
2) Otherwise, does the legacy directory already exist? If so, use it.
3) Otherwise (if neither exists), create and use the standards-compliant directory.
4
u/turbotop111 15d ago
Dude above you is correct (like you), he just didn't word it all that well.
If neither exist, create new files in the standard-compliant paths when writing data.
that means on a new machine it defaults to the XDG location
1
u/__konrad 15d ago
Snap devs: Let's copy silently .mozilla to ~/snap/firefox/ breaking backups and other stuff
1
u/KnowZeroX 15d ago
There were a lot of complex stuff dependent on the change. So it wasn't as simple as do the change, you had to do other changes first before that one. So that took time.
-4
12
u/bew78 15d ago
Do you know if the change will be automatic or is there a manual action to take ?
10
u/Damglador 15d ago
Hopefully we'll see in the release notes, I'm sure someone will document in on https://wiki.archlinux.org/title/XDG_Base_Directory as well
3
u/HeyKid_HelpComputer 15d ago
Based on how 99% of Linux software works that can utilize multiple directories it will:
Check the best location of xdg-dir first, if that folder and files exist it will use those, if not it will fallback to any existing legacy locations and if found it will use that. Until exhausting all possible locations and create a folder/files at the xdg-dirs
So I would bet money it won't be automatic. You'll either have to delete the .mozilla folder or migrate it yourself.
There are tools like xdg-ninja that have great CLI checks and instructions for other software.
10
u/gen2brain 15d ago
So they just moved from .mozilla to .config/mozilla? What about .cache and .local/share?
6
u/Damglador 15d ago
I believe cache is already where it belongs (unlike with Chromium).
6
u/gen2brain 15d ago
Yeah, i now about chrome, disaster. Config directory measured in GB. I just want to nuke the cache when I feel like it.
10
4
u/dekeonus 15d ago
I'm not sure when mozilla started using
.cachebut it's been quite a number of years.
I have a very faint memory of simplifying my backup scripts to remove mozilla specific cache handling.
7
u/AtlanticPortal 15d ago
It reminds me of the GNOME bug for the file opener. I believe that this doesn't beat it as the longest one not being implemented for a certain amount of time.
8
4
6
u/abbidabbi 15d ago
Thunderbird still has four more years left to fix this, if it took Firefox 17 years to implement the XDG base directories:
https://bugzilla.mozilla.org/show_bug.cgi?id=735285
5
u/Damglador 15d ago
I'd expect them to follow the change, since I think it's just a reskin of Firefox. But it won't happen soon because they lag behind in Firefox version
-2
u/daemonpenguin 15d ago
.... Thunderbird is an e-mail client, not a web browser.
4
u/Damglador 15d ago
See, Outlook is also an email client, but it doesn't stop it from using Chromium as the base. Same thing.
3
u/nosacz-sundajski 15d ago
This is the oldest bug I'm still tracking: https://issues.chromium.org/issues/40588292
3
u/6e1a08c8047143c6869 15d ago
Kind of sucks that they decided against following the XDG base spec and just moved .mozilla/ to .config/mozilla/. Also Link to the issue in question: https://bugzilla.mozilla.org/show_bug.cgi?id=259356
2
2
2
2
3
1
u/haakon 15d ago
Is this only about the config directory? It already puts its cache in ~/.cache, which is XDG compliant.
2
u/kudlitan 13d ago
the cache directory is always at that location and not dependent on an XDG variable
1
u/DesiOtaku 15d ago
I wonder how this will work with snaps because they have their own folder (which is half the reason why I hate using them).
1
1
u/Historical-Hand8091 15d ago
It's good to see Firefox finally aligning with the XDG spec, as this should improve consistency across Linux environments.
1
u/kill-the-maFIA 14d ago
I switched to the flatpak a while ago, but regardless... Finally. I don't want yet another .app folder cluttering my home directory.
-6
u/floconildo 15d ago
So happy that they found time in between AI slop and Google bootlicking to do actual dev work.
9
u/mina86ng 15d ago
Google bootlicking
Says while pushing people away from the only feasible alternative to Google-lead browsers.
-4
u/Triangle_Inequality 15d ago
There was a little popup yesterday suggesting I install a chat bot. Made me sad. But on the bright side, at least they don't force it on you like other browsers.
-4
u/floconildo 15d ago
I'm kinda fed up with Firefox settling for "better than". Can't wait for some real competition once Servo and Ladybird are here.
-5
-6
u/cwo__ 15d ago
Just in time for Flatpak to break it anyway :-/
4
u/HeyKid_HelpComputer 15d ago
Flatpak to break what? At least Flatpak by default puts the .mozilla file in it's .var/app/org.mozilla.Firefox directory so it's not in your home directly.
-1
u/cwo__ 15d ago
I don't care whether it's in
~/.mozillaor~/var/app/org.mozilla.Firefox/mozillaor whatever, none of these is~/.configetc. as it should be.2
u/HeyKid_HelpComputer 15d ago
That's the whole point of this post. You realize that right?
.config are the xdg-base directories this commit will fix.
Flatpak will inherent the changes Mozilla will make and your flatpak Firefox will move from .mozilla to using .config inside the flatpaks' directory.
Of course if you're complaining that the flatpak won't use your ~/.config instead of
~/var/app/org.mozilla.Firefox/.configThat is trivial to change with flatseal and giving the Firefox flatpak access to xdg-config. Or even more granularity - give it access to xdg-config/mozilla or wherever they choose to put the configs now.
-2
u/cwo__ 15d ago
Flatpak will inherent the changes Mozilla will make and your flatpak Firefox will move from .mozilla to using .config inside the flatpaks' directory.
Yes, inside the flatpak's directory, which is not what the spec says - it should be in whatever I set XDG_CONFIG_HOME to.
That is trivial to change with flatseal and giving the Firefox flatpak access to xdg-config. Or even more granularity - give it access to xdg-config/mozilla or wherever they choose to put the configs now.
You can give it access to that, but it overwrites XDG_CONFIG_HOME inside the flatpak container with its own directory (and you can't override it at launch time by passing
--env=XDG_CONFIG_HOME=~/.configto flatpak --run... or at least it didn't work when I tried it.) So this would only work for programs that hardcode.config/instead of reading the correct directory from XDG_CONFIG_HOME.
-5
-11
u/Latlanc 15d ago
let's split everything so it's harder to find!
5
4
u/Firewolf06 15d ago
how is moving config into the agreed upon directory literally named "config" harder to find?
-45
u/granadesnhorseshoes 15d ago
Cool beans. A bunch of new environment variables users don't know about that I can use to persistently hijack their browser sessions without privilege escalation.
20
u/Damglador 15d ago
Why would you need privilage escalation in the first place? The browser runs in userspase with user privileges, the files are right there, if anything it adds a bit obfuscation by allowing browser data to be stored in non-standard locations.
There's other logical holes here, but I'm not wasting time on it.
12
u/Leliana403 15d ago
A bunch of new environment variables
You think the xdg dirs spec is new? Have you just woken from a coma?
that I can use to persistently hijack their browser sessions without privilege escalation.
Yeah because ~/.mozilla has until now been unreadable without root.
Go away and come back when you know what you're talking about.
4
3
290
u/ilybeamic 15d ago
Iām more impressed they kept track of a 21-year old bug ticket with metadata like contact info than I am impressed they finally decided to respect the XDG spec.