* 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.
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.
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.
> 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)
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).
That's why they should copy Vivaldi and allow custom context menus where you can add/remove/rename.
Customization is how you rectify those centralized UI mistakes
> 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.
> 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.
Chromium is still polluting stuff with $HOME/.pki because it's not using libnss correctly and developers don't care to fix it, despite a longstanding open bug report.
Which results in everything that embeds Chromium (like QtWebEngine and etc.) polluting $HOME as well.
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.
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.
Readit News
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?
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.
Deleted Comment
So no migration to the XDG directory, but also no throwing away your existing data either.
Who knows what might be touching that data today. Or backing it up, etc
[0] https://hg-edge.mozilla.org/integration/autoland/rev/8a6d6c0...
Which already is a huge improvement and better than bikeshedding for decades that they also should use $HOME/.local/share/mozilla in addition.
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.
See https://wiki.archlinux.org/title/XDG_Base_Directory.
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.
(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).
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
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=259356
More of this, less AI-cramming, please!
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
> 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
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.
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.
Which results in everything that embeds Chromium (like QtWebEngine and etc.) polluting $HOME as well.
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
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!
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).
Now you have even more complexity. Programs will have to know where this "virtual" path is unless you're suggesting it should be hard-coded.
> on *nix, all paths are virtual anyways
What does this mean?
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.
Deleted Comment
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.
[1] Could (and should) implement a verification step as well.
Deleted Comment
Deleted Comment