* there doesn't appear to be any migration from old directory to new directory. Does the code just use ~/.mozilla if it still exists, ~/.config/mozilla otherwise.. or does it _require_ MOZ_LEGACY_HOME=1 to be set to keep using your existing config, and just lose all config if you don't set that?
* there doesn't appear to be a proper split between ~/.cache (always-removable cached data) ~/.config (configuration) and ~/.local/share (application data that is not user-editable configuration and is not just cached data either), they just moved the entire set of profile stuff to ~/.config
Is that about right, or do I need to read the code more carefully?
> At last! Mozilla fixing longstanding bugs! (I jest)
you joke but they did just close out the initial implementation of a something like 27 year old bug. about:keyboard was recently added to nightly to allow you to change or clear the built in keyboard shortcuts of a bunch of menu items like save, back, refresh, or open dev tools or whatever.
You can also tell Firefox to ignore it completely:
browser.quitShortcut.disabled
As well as to warn:
browser.warnOnQuit
browser.warnOnQuitShortcut
Well, apparently I once was aware of these because I have it set in my custom user.js. But I guess ctrl-q will always be lock screen for me, old habits die hard.
I installed this extension 5 minutes ago and it's already such an improvement. Never occured to me that there can be extensions to override shortcut defaults.
From that diff it looks to me that if ~/.mozilla exists OR if MOZ_LEGACY_HOME is set it uses ~/.mozilla, otherwise it uses the $XDG_CONFIG_HOME/.mozilla directory instead.
So no migration to the XDG directory, but also no throwing away your existing data either.
I know a few apps that did the same (mpv for example). If you still have it in home root it uses that, when you move it to .config it uses that instead. Auto migrating could and would create issues.
It seems Firefox doesn't really rely on these. My profile directory has been around for more than a decade, went through three computers and even between Windows and Linux and from plain Firefox to Firefox Developer Edition and pretty much everything transferred just by copying the files around (however i didn't copy the full Mozilla directory, first i let Firefox make a new empty profile by itself and copy/pasted the files in it, overwriting whatever was already there).
It even had the original XUL-based DownThemAll version, got disabled after XUL addons were disabled and some time one or two years later it got re-enabled again after the dev released a webextensions compatible version (sadly with several limitations, but still useful for bulk downloads).
Amusingly, there are a couple Windows absolute paths in there even though this profile has been on Linux for a few years now :-P
Interesting. I have had extensions lose their storage when the profile directory path changed, and at the time it seemed to be because of the pathnames within the files.
This is very important to know if this is really the case. And if it is, then what is the best way to migrate? Is there an official, supported method if "mv" is not it?
Looking at the full diff[0] it certainly looks like it's using ~/.cache (and has been for some time), but I cannot see anything about ~/.local/share, no.
Which means my .config directory, which is under backup, is gonna be spammed with temporary and cache files. Though not XDG-compliant, at least ~/.mozilla was in place for decades and it’s already being excluded in my backup set on my machines.
Either they adopt XDG fully, putting cache files where they belong, or don’t just change things haphazardly for little benefit.
Not cache files if I understand correctly, they are using $HOME/.cache/mozilla for a long time already.
You can exclude $HOME/.config/mozilla from your back up all the same anyway if that causes you some issues.
I personally appreciate them not cluttering $HOME with this move. It is better than waiting another 21 years for them to support XDG spec fully by splitting share and config.
> there doesn't appear to be a proper split between ~/.cache (always-removable cached data) ~/.config (configuration) and ~/.local/share
If that’s true, the title of the issue (and blog post) is quite untrue. Shoving everything in ~/.config is different than following the XDG Base Directory spec.
At least it’s one dotfile less that’s polluting my home.
I think there is probably a lot of work to do to fully pry the .mozilla folder apart. For a long time they've simply shipped everything in that folder and rolled with it. Making decisions on what is actually cache and what is user config vs "application data" is probably going to be harder than splitting the folder.
That's true, but they've already done it for macOS... ~/Library/Application Support/Firefox/ (for both the config and non-config data) versus ~/Library/Caches/Firefox/ (for cached data that can always be deleted)
Oh, I hadn't even _thought_ of that. Yeah, that's going to be a fun debate. Realistically, extensions shouldn't care about the folder structure of other parts of the profile, but I also know that there is a _lot_ of history there.
Requiring a mozconfig file shows that the code base has failed to transition to cmake or meson/ninja (directly; there is some python wrapper which may help here but I refer to the primary configuration). Mozilla gave up on Firefox a long time ago already.
Someday they'll stop changing the context menu if I accidentaly select something.
(Some UX designer or developer thought it was a great idea to remove the back and forward buttons from the context menu if text is selected so now I have two different context menus and one of them lack the thing I am looking for most of the time which is the back button.
Or fixing the tabstrip API (someone has decided we users are now too stupid to use only tree style tabs and for our own good we must be prevented from hiding the original tab bar).
> so now I have two different context menus and one of them lack the thing I am looking for most of the time
This annoys me constantly trying to get Firefox to show the “Take Screenshot” context-menu item. Yes I know about Control+Shift+S, but I'm still annoyed when my hand is already on the mouse and it won't do what I want.
You may jest, but sadly, that was my first knee-jerk reaction to the headline, too. "Wow, Mozilla actually fixes Firefox bugs? Let's go!" This is how low the bar has gotten :(
This is a meaningful step! For years, XDG Base Directory compliance has been spotty across major applications. Firefox's adoption matters because it's widely used and its implementation may encourage others to follow suit.
The Arch Wiki documentation will likely need updates [1], but sadly the list of non-compliant software is far too long.
FWIW, the OpenSSH devs believe it to be a potential security risk to adopt XDG:
> Adding additional configuration paths is confusing and potentially risky
for .ssh as, quite unlike usual "desktop" apps, it grants system access and having its configuration smeared across several possible paths makes managing this more confusing and brittle.[1]
I think this is clearly true for something like ~/.ssh/authorized_keys; it is perhaps less true for ~/.ssh/config and or ~/.ssh/known_hosts which could go in XDG_CONFIG_HOME and XDG_DATA_HOME, but if part of the point of the XDG BDS is to reduce dotfiles in $HOME then it makes less sense to move some, but not all of those files.
I think most people are okay with software such as OpenSSH keeping its long-existing conventions. In the same way I don't think a lot of people mind ".bashrc" being where it is. It's manageable if there's just a few and they're well-known.
However this "exemption" does not and should not apply to anything newer. Things like Cargo, Snap, Steam, Jupyter, Ghidra, Gradle, none of those should be putting their stuff (especially temporary junk) directly and unsegmented into $HOME.
At some point I had more than 50 different dotfiles and dotfolders in my $HOME. It was unwieldy and nasty to look at. I couldn't even figure out what created some of those files because they were so generic.
Plain $HOME as the dumping ground simply does not scale beyond a select few.
It's been a while since I used Windows, but I remember the "My Documents" folder being trash pile of configs, save games, data files and whatnot, making it the worst place to actually store your documents.
Windows-oriented developers bring that mess to Macs, too, and it's incredibly aggravating. For over 25 years, Apple has had Documents/Pictures/Movies/Applications/Downloads/etc folders under the user's home folder, and convention is predominantly that you never put non-hidden files or folders in the user's home directory. And you don't put application configuration in Documents, because that's what ~Library is for.
Then ignorant developers who don't care about the platform throw random configuration folders in ~/ or ~/Documents, or think their app needs a central workspace folder for all of its projects, instead of letting you manage your own damn files.
> configuration smeared across several possible paths
This does make things confusing, and while it may be inconvenient, it is not a security risk.
I use firejail with most apps and they do not have access to any other files than their own (most of the time).
FWIW, I am completely fine with ~/.ssh and I hope it keeps being ~/.ssh. I prefer SSH-related stuff to be in one place. Same with ~/.gnupg. I do not want to miss anything when I am making backups.
Mmm...not exactly. When security is difficult, the default fix is to turn it off, workaround, etc. Security should be relatively simple.
Increasing the difficulty of correctly configuring additional directories increases the chance something "bad" may happen. As a theorical example, for ssh say that config is not protected the same way keys are (on the file system or by policy). Pair this with some option that, when configured, exposes the contents of the keys.
Increasing the complexity required to secure something makes it inherently less secure.
the most "fun" I had it with the mess recently was after icedove -> thunderbird name migration (it was renamed in Debian coz of some trademark issue).
Tunderbird, of course, kept mail and config in same directory. The migration process renamed .icedove to .thunderbird and removed it.
But the config for mailboxe still had .icedove/xyz path. So once config migration is finished, mails start to download in old location, and after restarting thunderbird goes "hey, there is both .icedove and .thunderbird dir, I'm not starting".
with XDG that config would be separate so there would be no need to even move the data dir
Annoyingly, many programs hardcode ~/.config and ~/.local (instead of using XDG_CONFIG_HOME etc) and try to recreate them every time they run. This is a good indication to stop using these careless programs!
I despise programs that think they can just run a goddamn train on my home directory. I'm sick of hidden files I'm expected to edit by hand for configuration. I sick of ugly dotfiles everywhere.
This is great news. Firefox respects the system-defined folders on Windows and macOS. Linux, being the free spirit it is, doesn't have a 'standard'. XDG makes recommendations that make a certain amount of sense and aligning to that is a great step forward for such a large project.
The reason most software is not "XDG-compliant" is because most software predates the XDG basedir spec which only came into existence in 2021 (edit: oops, that's just version 0.8; version 0.6 was available in 2003)
It will be nice for software, as it updates, to support this standard which seems to be gaining adoption, and it will make users homedirs much cleaner. But it's most important for software to _keep working_, and have a migration path that doesn't lose the user's config or end up with two configs and not have a clear rule on which one it will use.
I think it is possible for software to keep working and I can think of many ways to implement automatic "migration", which is essentially just copying files to the new directory (or just do a move operation which is atomic) and then deleting the previous directory if the copy was successful[1], and if one wants, could create a compressed backup of the directory prior to doing that.
[1] Could (and should) implement a verification step as well.
> which is essentially just copying files to the new directory and then deleting the previous directory if the copy was successful
And deleting the partially copied data if the copy wasn’t successful, and making sure “just copying files to the new directory” didn’t overwrite data, and probably a few more tricky scenarios, e.g. ones involving access rights.
Also, if you think it could be a directory rename, there are tricky corners there, too. How do you determine whether source and target are on the same disk, for example?
It _is_ possible, but doing it robustly is far from trivial.
You are listing edge cases that exist, but the relevant question is whether they meaningfully apply to Firefox profile migration on typical systems.
Same-disk detection can be done through stat() on both paths and comparing st_dev, which is trivial. But more importantly, why does this matter for migration? If it is cross-filesystem, copy and move works fine. If you are concerned about atomicity, that is a different problem, but Firefox profiles are not typically manipulated concurrently during a migration that happens once at startup.
Partial copy cleanup is reasonable, but again, context matters. For a one-time migration triggered at browser start with exclusive access to the profile, you verify checksums or sizes post-copy, and if verification fails, you do not delete the source. User gets an error, tries again later. Not complex.
As for overwrites: do not overwrite if target exists. Check once before starting. If the XDG path already has data, skip migration entirely or prompt. This is not a continuous sync operation.
FWIW "cp -a" preserves access rights on Unix. On Windows, ACLs can be trickier but for user-owned profiles it is usually a non-issue.
The real complexity in robust file operations show up with network filesystems (SMB, NFS), concurrent access patterns, or where atomicity guarantees are critical (and a move operation is indeed atomic, assuming typical systems). For a single-user profile migration that happens once with exclusive lock? The corner cases you mentioned are either straightforward to handle or do not apply.
First .mkv support and now this! I really like what Firefox has been doing recently. The only major annoyance that still remains is hard-coded keyboard shortcuts, fingers crossed!
Firefox Nightly has about:keyboard (as I just found out from the comment thread on phoronix). Hopefully it sticks. It's bare-bones but functional and I like it that way.
So... did they also implement the horrendous quirk of Chrome that breaks XDG when XDG_DESKTOP_DIR and XDG_DOWNLOAD_DIR point to the same directory? It probably costed a combined million hours wasted and made many people genuinely hate Linux
I’m not sure if its because of my ad blocker but I get the occasional link that wont click when I am say going through a job application flow. Could be the way their saas vender implements things. For things that are important like that or say banking/credit card websites I usually am forced to defer to Safari.
I think the XDG spec is pretty petty. What difference does it make that the files are in ~/.config/mozilla instead of ~/.mozilla? And calling it a bug is presumptuous.
The difference is that I don’t use standard XDG directories because I loathe dot-files, loathe hidden directories, and so I declare my own environment variables to put everything where I want.
Then Firefox (and ansible, and many others) comes barreling in dropping an unconfigurable dot-directory in my fucking home folder ignoring the perfectly good XDG variables I have set.
It is a constant struggle to stop my home folder from not feeling like my home. Developers ought to learn some fucking respect.
This, I set an alias for `adb` to use `"$XDG_DATA_HOME"/android` instead of `~/.android` because it stores the keys there for whatever reason. I would rather not see my home folder being cluttered with hidden files, it makes backing things up unnecessarily complex.
export ANDROID_USER_HOME="$XDG_DATA_HOME"/android
alias adb='HOME="$ANDROID_USER_HOME" adb'
One being that it's _my_ $HOME, not some random developers'. I literally had more than 50 different dotfiles and dotfolders in my $HOME at some point. It was a garbage dump and I couldn't even identify the culprit with some of them. Simply disrespectful.
Then there's the issue of cleaning up leftovers and stale cache files. It shouldn't take a custom script cleaning up after every special snowflake that decided to use some arbitrarily-named directory in $HOME.
Not following the spec also makes backing up vital application state much much harder.
In the end, I made my $HOME not writeable so I could instantly find out if some software wants to take a dump. It turns out it's often simply unnecessary as well, the software doesn't even care, just prints an error and continues.
the main benefit (which even with this change, Firefox won't get) is the separation of configuration, cache files, binaries etc which sysadmins likely want completely different policies for. e.g. cache shouldn't be backed up, config shouldn't be executable etc
Have you ever `ls -al ~/` on a heavily used unix system? Absolute rot and chaos. I have like 100 hidden directories+files in the root of my home directory. Some of them are caches, some are configs.
I don't like Unix filesystem structure in general. What's the point of having directories like /usr or /lib in the root directory, when they could be all under for example, /ubuntu24? And the user could keep files in the root directory and not in /home with lot of system files.
Also I don't like that some distributions suggest partitioning a drive. This is inconvenient, because you can run out of space at one partition, but have lot of free space at another. It simply doesn't make sense. And if you have swap as a partition, you get slightly faster access, but cannot change the size!
> you can run out of space at one partition, but have lot of free space at another
that's exactly the point — you can run out of space in your /home but that does not affect, for example, /var. or vice versa, log explosion in /var is contained within its own partition and does not clog the entire filesystem.
very important for /var/log, pretty easy to have log spamming app fill the drive, and you don't want logs filling get your database into out of disk space state
There are a lot of reasons. Just three from the top of my head:
1. The way Unix works, a directory is a file, so if you can write in a directory you'll also be able to move directories around (and thus break the structure you mentioned completely).
2. Doesn't make sense for multi-user. Yes, I understand most people have their own computers, but (1) why design it in a way that breaks multi-user unnecessarily? (2) there are a lot of utility users, and having them get access to user files because of the way this is structured is silly.
3. `grep -r` is going to be a pain in the ass when searching your own files, because it'll also search all the other system subdirectories too.
It’s just historical. Believe the large number of top level directories was a result of ken not having enough space on a single disk on his PDP, when that was precious.
For years I’ve been putting all user data into a separate /data partition and have kept the OS partition small (~30gb). But you have to fix the system when first installed. When I still used Windows I had the same c:/d: split.
More recently started putting kernels into a bigger ESP (EFI) partition with sdboot or uki.
With terabyte system disks, running out of space mostly doesn’t happen anymore unless you made the system partition(s) small. Don’t do that, give them plenty of GB, each of which are now thousandths of the disk.
I’m honestly having issues deciding if this is bait or not. Surely you understand that UNIX is a multi-user operating system and that partitioning drives exactly for the reason you describe is critical to ensure that, for example, runaway log growth doesn’t cause a database to shut down?
Today, in 2025, neither are safe assumptions to make. Much in line with the Internet meme's of "new college freshmen in 2025 have never known a world without cell phones" and the like, in 2025 there is now some rather large subset of the computer using population who have never known of nor used a "multi-user computer" and have only ever seen and used "single user computers" (even if the OS on their computer is inherently multi-user, the overall 'computer' is 'single-user' from their viewpoint).
And, if they have never seen nor used "multi-user computers" they also have not encountered "runaway log growth" or the like -- or if they did it was from their own process that they immediately killed, not by some other user on the same computer filling /var/log/ in the background.
AI startup idea: A plugin that scores HN posts on likelihood of bait. ChatGPT when prompted "Give [the post] a score from 1 to 10, where 1 is complete sincerity and 10 is low effort bait" thinks this is 7.
At last! Mozilla fixing longstanding bugs! (I jest)
The devil is in the details though: https://hg-edge.mozilla.org/integration/autoland/diff/8a6d6c...
Looking briefly at this,
* there doesn't appear to be any migration from old directory to new directory. Does the code just use ~/.mozilla if it still exists, ~/.config/mozilla otherwise.. or does it _require_ MOZ_LEGACY_HOME=1 to be set to keep using your existing config, and just lose all config if you don't set that?
* there doesn't appear to be a proper split between ~/.cache (always-removable cached data) ~/.config (configuration) and ~/.local/share (application data that is not user-editable configuration and is not just cached data either), they just moved the entire set of profile stuff to ~/.config
Is that about right, or do I need to read the code more carefully?
> At last! Mozilla fixing longstanding bugs! (I jest)
you joke but they did just close out the initial implementation of a something like 27 year old bug. about:keyboard was recently added to nightly to allow you to change or clear the built in keyboard shortcuts of a bunch of menu items like save, back, refresh, or open dev tools or whatever.
Is CRTL-Q included? They always insisted that applications can't change that shortcut on Linux.
Ctrl-Q (quit application) right next to Ctrl-W (close tab) has been bad UX since forever.
I bind ctrl-q to lock screen in gnome, which is less bad than losing the whole browser.
I suppose you could also bind it to a noop.
You can tell firefox to ask before quitting ...
You can also tell Firefox to ignore it completely:
As well as to warn: Well, apparently I once was aware of these because I have it set in my custom user.js. But I guess ctrl-q will always be lock screen for me, old habits die hard.> Ctrl-Q (quit application) right next to Ctrl-W (close tab)
That bug was actually fixed in the Dvorak release...
yes... https://i.imgur.com/8a9Jbj6.png
I need source on that Ctrl+Q thing
https://i.imgur.com/8a9Jbj6.png it seems to be available to remap/cancel.
Holy shit does this mean I can disable Ctrl-Shift-C and get my muscle memory for terminal copy back?
There's an extension for that. Quite handy for in-browser terminals like one in AWS etc.
https://addons.mozilla.org/en-US/firefox/addon/ctrl-shift-c-...
I installed this extension 5 minutes ago and it's already such an improvement. Never occured to me that there can be extensions to override shortcut defaults.
Thanks!
as a matter of fact... yes https://i.imgur.com/0uxzr4H.png
This was my first thought too!
was that a bug though? cuz it sounds like it was just a new feature that was added
From that diff it looks to me that if ~/.mozilla exists OR if MOZ_LEGACY_HOME is set it uses ~/.mozilla, otherwise it uses the $XDG_CONFIG_HOME/.mozilla directory instead.
So no migration to the XDG directory, but also no throwing away your existing data either.
That’s the safest.
Who knows what might be touching that data today. Or backing it up, etc
I know a few apps that did the same (mpv for example). If you still have it in home root it uses that, when you move it to .config it uses that instead. Auto migrating could and would create issues.
So is it safe to just manually move $HOME/.mozilla to $HOME/.config/mozilla ?
I would guess not. I see `.mozilla` absolute pathnames within some files in a profile directory (specifically, `extensions.json` and `pkcs11.txt`).
(This has bitten me before. I don't know why it was done that way.)
It seems Firefox doesn't really rely on these. My profile directory has been around for more than a decade, went through three computers and even between Windows and Linux and from plain Firefox to Firefox Developer Edition and pretty much everything transferred just by copying the files around (however i didn't copy the full Mozilla directory, first i let Firefox make a new empty profile by itself and copy/pasted the files in it, overwriting whatever was already there).
It even had the original XUL-based DownThemAll version, got disabled after XUL addons were disabled and some time one or two years later it got re-enabled again after the dev released a webextensions compatible version (sadly with several limitations, but still useful for bulk downloads).
Amusingly, there are a couple Windows absolute paths in there even though this profile has been on Linux for a few years now :-P
Interesting. I have had extensions lose their storage when the profile directory path changed, and at the time it seemed to be because of the pathnames within the files.
This is very important to know if this is really the case. And if it is, then what is the best way to migrate? Is there an official, supported method if "mv" is not it?
That’s the hard part to answer, that Mozilla leaves to you!
I think yes. And that's maybe the reason they didn't properly split the files to .cache/ .config etc
Looking at the full diff[0] it certainly looks like it's using ~/.cache (and has been for some time), but I cannot see anything about ~/.local/share, no.
[0] https://hg-edge.mozilla.org/integration/autoland/rev/8a6d6c0...
Nope, they just moved $HOME/.mozilla to $HOME/.config/mozilla it seems.
Which already is a huge improvement and better than bikeshedding for decades that they also should use $HOME/.local/share/mozilla in addition.
Which means my .config directory, which is under backup, is gonna be spammed with temporary and cache files. Though not XDG-compliant, at least ~/.mozilla was in place for decades and it’s already being excluded in my backup set on my machines.
Either they adopt XDG fully, putting cache files where they belong, or don’t just change things haphazardly for little benefit.
Not cache files if I understand correctly, they are using $HOME/.cache/mozilla for a long time already.
You can exclude $HOME/.config/mozilla from your back up all the same anyway if that causes you some issues.
I personally appreciate them not cluttering $HOME with this move. It is better than waiting another 21 years for them to support XDG spec fully by splitting share and config.
> You can exclude $HOME/.config/mozilla from your back up all the same anyway if that causes you some issues.
And then just not have Firefox backups?
Person above already didn't have them, so not sure what you are asking.
> there doesn't appear to be a proper split between ~/.cache (always-removable cached data) ~/.config (configuration) and ~/.local/share
If that’s true, the title of the issue (and blog post) is quite untrue. Shoving everything in ~/.config is different than following the XDG Base Directory spec.
At least it’s one dotfile less that’s polluting my home.
I agree, because of XDG_CONFIG_HOME vs. XDG_CACHE_HOME vs. XDG_DATA_HOME.
See https://wiki.archlinux.org/title/XDG_Base_Directory.
I think there is probably a lot of work to do to fully pry the .mozilla folder apart. For a long time they've simply shipped everything in that folder and rolled with it. Making decisions on what is actually cache and what is user config vs "application data" is probably going to be harder than splitting the folder.
That's true, but they've already done it for macOS... ~/Library/Application Support/Firefox/ (for both the config and non-config data) versus ~/Library/Caches/Firefox/ (for cached data that can always be deleted)
Extension data also lives in the profile folder. Some of those might start failing because of splitting up the profile into multiple folders.
Oh, I hadn't even _thought_ of that. Yeah, that's going to be a fun debate. Realistically, extensions shouldn't care about the folder structure of other parts of the profile, but I also know that there is a _lot_ of history there.
> I think there is probably a lot of work to do to fully pry the .mozilla folder apart.
So, things change over time. The question is: is the codebase at Mozilla still "living" in that it can adjust or be adjusted?
https://www.linuxfromscratch.org/blfs/view/svn/xsoft/firefox...
Requiring a mozconfig file shows that the code base has failed to transition to cmake or meson/ninja (directly; there is some python wrapper which may help here but I refer to the primary configuration). Mozilla gave up on Firefox a long time ago already.
FYI, they do use $HOME/.cache/mozilla already for a long time.
Someday they'll stop changing the context menu if I accidentaly select something.
(Some UX designer or developer thought it was a great idea to remove the back and forward buttons from the context menu if text is selected so now I have two different context menus and one of them lack the thing I am looking for most of the time which is the back button.
Or fixing the tabstrip API (someone has decided we users are now too stupid to use only tree style tabs and for our own good we must be prevented from hiding the original tab bar).
> so now I have two different context menus and one of them lack the thing I am looking for most of the time
This annoys me constantly trying to get Firefox to show the “Take Screenshot” context-menu item. Yes I know about Control+Shift+S, but I'm still annoyed when my hand is already on the mouse and it won't do what I want.
Although perhaps I should stop using that feature since I just while writing this comment realized how much it spies on you: https://probes.telemetry.mozilla.org/?search=screenshots
That domain is blocked on my network. What kind of information is it collecting?
Events:
Counters: inb4 mention of “Send technical and interaction data to Mozilla” setting, like it's okay for software to be privacy-adversarial by default lolMaybe I'm just too stupid, but goddamn what could the possible value in knowing if someone cancelled a screenshot or something. Like, *who cares*
You may jest, but sadly, that was my first knee-jerk reaction to the headline, too. "Wow, Mozilla actually fixes Firefox bugs? Let's go!" This is how low the bar has gotten :(
More of this, less AI-cramming, please!
I was curious about how old the original bug report was, and it appears to be 21 years old [0]!
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=259356
It’s right in the first sentence of the article.
This is a meaningful step! For years, XDG Base Directory compliance has been spotty across major applications. Firefox's adoption matters because it's widely used and its implementation may encourage others to follow suit.
The Arch Wiki documentation will likely need updates [1], but sadly the list of non-compliant software is far too long.
[1]: https://wiki.archlinux.org/title/XDG_Base_Directory
FWIW, the OpenSSH devs believe it to be a potential security risk to adopt XDG:
> Adding additional configuration paths is confusing and potentially risky for .ssh as, quite unlike usual "desktop" apps, it grants system access and having its configuration smeared across several possible paths makes managing this more confusing and brittle.[1]
I think this is clearly true for something like ~/.ssh/authorized_keys; it is perhaps less true for ~/.ssh/config and or ~/.ssh/known_hosts which could go in XDG_CONFIG_HOME and XDG_DATA_HOME, but if part of the point of the XDG BDS is to reduce dotfiles in $HOME then it makes less sense to move some, but not all of those files.
1: https://marc.info/?l=openssh-unix-dev&m=170687803731931&w=2
I think most people are okay with software such as OpenSSH keeping its long-existing conventions. In the same way I don't think a lot of people mind ".bashrc" being where it is. It's manageable if there's just a few and they're well-known.
However this "exemption" does not and should not apply to anything newer. Things like Cargo, Snap, Steam, Jupyter, Ghidra, Gradle, none of those should be putting their stuff (especially temporary junk) directly and unsegmented into $HOME.
At some point I had more than 50 different dotfiles and dotfolders in my $HOME. It was unwieldy and nasty to look at. I couldn't even figure out what created some of those files because they were so generic.
Plain $HOME as the dumping ground simply does not scale beyond a select few.
A sampling...
>$HOME as the dumping ground
It's been a while since I used Windows, but I remember the "My Documents" folder being trash pile of configs, save games, data files and whatnot, making it the worst place to actually store your documents.
Windows-oriented developers bring that mess to Macs, too, and it's incredibly aggravating. For over 25 years, Apple has had Documents/Pictures/Movies/Applications/Downloads/etc folders under the user's home folder, and convention is predominantly that you never put non-hidden files or folders in the user's home directory. And you don't put application configuration in Documents, because that's what ~Library is for.
Then ignorant developers who don't care about the platform throw random configuration folders in ~/ or ~/Documents, or think their app needs a central workspace folder for all of its projects, instead of letting you manage your own damn files.
how else will you remember where you stored your 3d objects
> configuration smeared across several possible paths
This does make things confusing, and while it may be inconvenient, it is not a security risk.
I use firejail with most apps and they do not have access to any other files than their own (most of the time).
FWIW, I am completely fine with ~/.ssh and I hope it keeps being ~/.ssh. I prefer SSH-related stuff to be in one place. Same with ~/.gnupg. I do not want to miss anything when I am making backups.
> inconvenient, it is not a security risk
Mmm...not exactly. When security is difficult, the default fix is to turn it off, workaround, etc. Security should be relatively simple.
Increasing the difficulty of correctly configuring additional directories increases the chance something "bad" may happen. As a theorical example, for ssh say that config is not protected the same way keys are (on the file system or by policy). Pair this with some option that, when configured, exposes the contents of the keys.
Increasing the complexity required to secure something makes it inherently less secure.
Okay, that makes sense and I do not disagree.
the most "fun" I had it with the mess recently was after icedove -> thunderbird name migration (it was renamed in Debian coz of some trademark issue).
Tunderbird, of course, kept mail and config in same directory. The migration process renamed .icedove to .thunderbird and removed it.
But the config for mailboxe still had .icedove/xyz path. So once config migration is finished, mails start to download in old location, and after restarting thunderbird goes "hey, there is both .icedove and .thunderbird dir, I'm not starting".
with XDG that config would be separate so there would be no need to even move the data dir
that's great!
The ~/.mozilla folder is one of the last remaining dotfiles in my home directory
You can also be an xdg ninja if you want: https://github.com/b3nj5m1n/xdg-ninjaAnnoyingly, many programs hardcode ~/.config and ~/.local (instead of using XDG_CONFIG_HOME etc) and try to recreate them every time they run. This is a good indication to stop using these careless programs!
(hard) links to the rescue.
I like environment variables, but developers/operating systems have trouble using them well.
I could almost see XDG_CONFIG_HOME being a setting read by a driver that provides access to a "virtual" path (on *nix, all paths are virtual anyways).
TIL about xdg-ninja, thanks for sharing.
I despise programs that think they can just run a goddamn train on my home directory. I'm sick of hidden files I'm expected to edit by hand for configuration. I sick of ugly dotfiles everywhere.
This is great news. Firefox respects the system-defined folders on Windows and macOS. Linux, being the free spirit it is, doesn't have a 'standard'. XDG makes recommendations that make a certain amount of sense and aligning to that is a great step forward for such a large project.
About time. Every piece of software should be XDG-compliant. I am surprised it was not the case at all to begin with.
XDG is newer than firefox and hasn’t been widely adopted for the majority of its life.
Do you mean Firefox specifically?
The reason most software is not "XDG-compliant" is because most software predates the XDG basedir spec which only came into existence in 2021 (edit: oops, that's just version 0.8; version 0.6 was available in 2003)
It will be nice for software, as it updates, to support this standard which seems to be gaining adoption, and it will make users homedirs much cleaner. But it's most important for software to _keep working_, and have a migration path that doesn't lose the user's config or end up with two configs and not have a clear rule on which one it will use.
I think it is possible for software to keep working and I can think of many ways to implement automatic "migration", which is essentially just copying files to the new directory (or just do a move operation which is atomic) and then deleting the previous directory if the copy was successful[1], and if one wants, could create a compressed backup of the directory prior to doing that.
[1] Could (and should) implement a verification step as well.
> which is essentially just copying files to the new directory and then deleting the previous directory if the copy was successful
And deleting the partially copied data if the copy wasn’t successful, and making sure “just copying files to the new directory” didn’t overwrite data, and probably a few more tricky scenarios, e.g. ones involving access rights.
Also, if you think it could be a directory rename, there are tricky corners there, too. How do you determine whether source and target are on the same disk, for example?
It _is_ possible, but doing it robustly is far from trivial.
You are listing edge cases that exist, but the relevant question is whether they meaningfully apply to Firefox profile migration on typical systems.
Same-disk detection can be done through stat() on both paths and comparing st_dev, which is trivial. But more importantly, why does this matter for migration? If it is cross-filesystem, copy and move works fine. If you are concerned about atomicity, that is a different problem, but Firefox profiles are not typically manipulated concurrently during a migration that happens once at startup.
Partial copy cleanup is reasonable, but again, context matters. For a one-time migration triggered at browser start with exclusive access to the profile, you verify checksums or sizes post-copy, and if verification fails, you do not delete the source. User gets an error, tries again later. Not complex.
As for overwrites: do not overwrite if target exists. Check once before starting. If the XDG path already has data, skip migration entirely or prompt. This is not a continuous sync operation.
FWIW "cp -a" preserves access rights on Unix. On Windows, ACLs can be trickier but for user-owned profiles it is usually a non-issue.
The real complexity in robust file operations show up with network filesystems (SMB, NFS), concurrent access patterns, or where atomicity guarantees are critical (and a move operation is indeed atomic, assuming typical systems). For a single-user profile migration that happens once with exclusive lock? The corner cases you mentioned are either straightforward to handle or do not apply.
Migration might be nontrivial but there's absolutely zero good excuse for creating _new_ noncompliant directories for 17 years.
There's lot less to migrate if you don't wait that long.
This is awesome! Been tracking the bug for what seems like Gimp 3 levels of time. But great job all involved.
First .mkv support and now this! I really like what Firefox has been doing recently. The only major annoyance that still remains is hard-coded keyboard shortcuts, fingers crossed!
Firefox Nightly has about:keyboard (as I just found out from the comment thread on phoronix). Hopefully it sticks. It's bare-bones but functional and I like it that way.
Not bad - with a delay of only 21 years, Firefox is just about to make a strong come back now. :D
Someone asked what the blocker is, and the guy replied:
I mean, he only had 21 years. :DI wonder if the original reporter is still around to see their enhancement ticket closed?
Perhaps their grand children are still around?
probably using chrome tho, FF really squandered the marketshare
Nothing they could do when the de facto search engine and de facto video player for the entire internet started shilling its own product relentlessly.
So... did they also implement the horrendous quirk of Chrome that breaks XDG when XDG_DESKTOP_DIR and XDG_DOWNLOAD_DIR point to the same directory? It probably costed a combined million hours wasted and made many people genuinely hate Linux
See here https://github.com/chromium/chromium/blob/5e4e38173b33159b0e...
Let's hope this will inspire other software developers to follow conventions and move their configs to appropriate directories.
I am wondering what other long standing bug or feature that is still missing on Firefox.
Firefox excel in terms of Multi Tab and memory usage. And I have yet to encounter a rendering issues in the past 12 months.
I’m not sure if its because of my ad blocker but I get the occasional link that wont click when I am say going through a job application flow. Could be the way their saas vender implements things. For things that are important like that or say banking/credit card websites I usually am forced to defer to Safari.
bless them
Bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=259356
Source: https://hg-edge.mozilla.org/integration/autoland/rev/8a6d6c0...
Sincere congrats! It only took 21 years.
Now that everyone is kindly on board, IBM can finally bury this standard. /s
Will it stop enabling dns over https by default?
I think the XDG spec is pretty petty. What difference does it make that the files are in ~/.config/mozilla instead of ~/.mozilla? And calling it a bug is presumptuous.
The difference is that I don’t use standard XDG directories because I loathe dot-files, loathe hidden directories, and so I declare my own environment variables to put everything where I want.
Then Firefox (and ansible, and many others) comes barreling in dropping an unconfigurable dot-directory in my fucking home folder ignoring the perfectly good XDG variables I have set.
It is a constant struggle to stop my home folder from not feeling like my home. Developers ought to learn some fucking respect.
This, I set an alias for `adb` to use `"$XDG_DATA_HOME"/android` instead of `~/.android` because it stores the keys there for whatever reason. I would rather not see my home folder being cluttered with hidden files, it makes backing things up unnecessarily complex.
Don't forget Gradle ("GRADLE_USER_HOME") and OpenJDK ("-Djava.util.prefs.userRoot"), those too litter.
You could try flatpak Firefox, if that works for you then it takes care of that
There are multiple reasons for this.
One being that it's _my_ $HOME, not some random developers'. I literally had more than 50 different dotfiles and dotfolders in my $HOME at some point. It was a garbage dump and I couldn't even identify the culprit with some of them. Simply disrespectful.
Then there's the issue of cleaning up leftovers and stale cache files. It shouldn't take a custom script cleaning up after every special snowflake that decided to use some arbitrarily-named directory in $HOME.
Not following the spec also makes backing up vital application state much much harder.
In the end, I made my $HOME not writeable so I could instantly find out if some software wants to take a dump. It turns out it's often simply unnecessary as well, the software doesn't even care, just prints an error and continues.
> In the end, I made my $HOME not writeable so I could instantly find out if some software wants to take a dump
A brilliant idea, but goddamn what a shame it is that we have to do such things to keep our homes clean
> It shouldn't take a custom script cleaning up after every special snowflake that decided to use some arbitrarily-named directory in $HOME.
Not to take away from your point but I shall introduce you to systemd-tmpfiles
no scripts needed, it can clean up for you if you keep a list of directories/files to clean up
the main benefit (which even with this change, Firefox won't get) is the separation of configuration, cache files, binaries etc which sysadmins likely want completely different policies for. e.g. cache shouldn't be backed up, config shouldn't be executable etc
Firefox already had the benefit with respect to cache files. They've been in ~/.cache/mozilla for at least 7 years now.
Your point is valid for config/data split, but that seems to be a judgement call and many applications do things differently there.
Have you ever `ls -al ~/` on a heavily used unix system? Absolute rot and chaos. I have like 100 hidden directories+files in the root of my home directory. Some of them are caches, some are configs.
I don't like Unix filesystem structure in general. What's the point of having directories like /usr or /lib in the root directory, when they could be all under for example, /ubuntu24? And the user could keep files in the root directory and not in /home with lot of system files.
Also I don't like that some distributions suggest partitioning a drive. This is inconvenient, because you can run out of space at one partition, but have lot of free space at another. It simply doesn't make sense. And if you have swap as a partition, you get slightly faster access, but cannot change the size!
> you can run out of space at one partition, but have lot of free space at another
that's exactly the point — you can run out of space in your /home but that does not affect, for example, /var. or vice versa, log explosion in /var is contained within its own partition and does not clog the entire filesystem.
very important for /var/log, pretty easy to have log spamming app fill the drive, and you don't want logs filling get your database into out of disk space state
There are a lot of reasons. Just three from the top of my head:
1. The way Unix works, a directory is a file, so if you can write in a directory you'll also be able to move directories around (and thus break the structure you mentioned completely).
2. Doesn't make sense for multi-user. Yes, I understand most people have their own computers, but (1) why design it in a way that breaks multi-user unnecessarily? (2) there are a lot of utility users, and having them get access to user files because of the way this is structured is silly.
3. `grep -r` is going to be a pain in the ass when searching your own files, because it'll also search all the other system subdirectories too.
It’s just historical. Believe the large number of top level directories was a result of ken not having enough space on a single disk on his PDP, when that was precious.
For years I’ve been putting all user data into a separate /data partition and have kept the OS partition small (~30gb). But you have to fix the system when first installed. When I still used Windows I had the same c:/d: split.
More recently started putting kernels into a bigger ESP (EFI) partition with sdboot or uki.
With terabyte system disks, running out of space mostly doesn’t happen anymore unless you made the system partition(s) small. Don’t do that, give them plenty of GB, each of which are now thousandths of the disk.
If one user kept their files in the root directory, where would a second user keep theirs?
Most operating systems mounts things dynamically. You can never trust that a path for you exists for another user.
This is a very recent aspect time wise in the very long history of Unix (and Linux) systems.
I’m honestly having issues deciding if this is bait or not. Surely you understand that UNIX is a multi-user operating system and that partitioning drives exactly for the reason you describe is critical to ensure that, for example, runaway log growth doesn’t cause a database to shut down?
Today, in 2025, neither are safe assumptions to make. Much in line with the Internet meme's of "new college freshmen in 2025 have never known a world without cell phones" and the like, in 2025 there is now some rather large subset of the computer using population who have never known of nor used a "multi-user computer" and have only ever seen and used "single user computers" (even if the OS on their computer is inherently multi-user, the overall 'computer' is 'single-user' from their viewpoint).
And, if they have never seen nor used "multi-user computers" they also have not encountered "runaway log growth" or the like -- or if they did it was from their own process that they immediately killed, not by some other user on the same computer filling /var/log/ in the background.
It's a learning experience, when you see something, ask yourself "why it is so complicated" and try to do it simpler
Then fix bug after bug after bug in your new "simpler" thing and realize why the thing you decided to "fix" was that complicated in the first place
AI startup idea: A plugin that scores HN posts on likelihood of bait. ChatGPT when prompted "Give [the post] a score from 1 to 10, where 1 is complete sincerity and 10 is low effort bait" thinks this is 7.
there is good chance with any bait to just have someone clueless.
I heard actual devs complaining they don't need logrotate because containers are restarted often enough...
Partitioning a drive lets you use different file systems on different parts.
It also lets you somewhat-better enforce things like:
* Setting some data aside as read-only-never-touch-it.
* Excluding some files and directories from searching and indexing.
although admittedly you don't _have_ to partition for that purpose.