Hacker News Reader

Comment by amiga386 | Hacker News Reader

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?

View on HN

> 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.

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!

This was my first thought too!

as a matter of fact... yes https://i.imgur.com/0uxzr4H.png

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:

    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.

> browser.quitShortcut.disabled

The setting is there, it's editable, but Firefox seems to completely ignore it on Linux.

At least up to 145.0.1.

I use 144.0.2 on Linux and it works entirely fine here.

Hmm, maybe it’s still necessary to rebind ctrl-q in some cases.

This says gnome has ctrl-q to quit applications:

https://wiki.gnome.org/Design/OS/KeyboardShortcuts

I don’t know if the above is still the default, but I have this in my gnome setup scripts anyway:

    gsettings set org.gnome.settings-daemon.plugins.media-keys screensaver “[‘<Control>q’]”

(IIRC it’s a terminal command because trying to bind ctrl-q in Settings will quit the Settings window. And you can’t unbind ctrl-q completely, so you have to bind it to something else. You could maybe add it as a custom launcher that just runs /bin/true.)

and testing it now, it asks me by default, and I never changed that setting

> Ctrl-Q (quit application) right next to Ctrl-W (close tab)

That bug was actually fixed in the Dvorak release...

On a German PC keyboard, @ is ALT+Q.

That was a big problem when I switched to macOS. I kept hitting CMD+Q every time I tried to type an email address.

I need source on that Ctrl+Q thing

https://i.imgur.com/8a9Jbj6.png it seems to be available to remap/cancel.

yes... https://i.imgur.com/8a9Jbj6.png

was that a bug though? cuz it sounds like it was just a new feature that was added

yeah they only have one system for it all and they are all called bugs.

here's the 25 year old bug. https://bugzilla.mozilla.org/show_bug.cgi?id=57805

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 ?

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

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.)

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?

There is an answer in the comment to the original bug:

> there is no migration path supported at this point: only new profiles are expected to use the new setup. Migrating manually is at your own risk, make a backup before.

I'll try to do it manually, replacing paths in the couple of files mentioned above first.

I hate to say it, but if there's no migration path, this improvement may not have been the best use of Mozilla's resources. Because who's creating new Firefox accounts in 2025? I mean I guess the folder will be in the right place the next time I do a fresh install, but I'd rather see them investing in stuff that grows their user base.

Better something simple than nothing. I'm glad they didn't use it as an excuse not to do it at all. I've seen this happening with other projects.

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.

I guess we can try replacing the value there manually to the new one before starting Firefox.

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.

about:cache says my firefox is using ~/.cache for cache. This is on version 144

Which is what I expect, yes.

> 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.

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.

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)

FYI, they do use $HOME/.cache/mozilla already for a long time.

> 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.

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:

  screenshots.canceled#canceled
  screenshots.copy#copy
  screenshots.download#download
  screenshots.failed#failed
  screenshots.selected#selected
  screenshots.started#started

Counters:

  screenshots.copy
  screenshots.custom
  screenshots.download
  screenshots.element
  screenshots.full_page
  screenshots.upload
  screenshots.visible

inb4 mention of “Send technical and interaction data to Mozilla” setting, like it's okay for software to be privacy-adversarial by default lol

Maybe I'm just too stupid, but goddamn what could the possible value in knowing if someone cancelled a screenshot or something. Like, *who cares*

Are you serious?

It is rather obvious why a software designer want to know how a piece of software is used and also to know it over time. If number of cancelled screenshots increases (or decreases) compared to general usage of the screenshot feature it might give an early indication that a recent change was bad (or good).

As long as it only logs counters like this and not who I am or any of my data or who I am I actually want them to log it and if it was disabled and there was an easy way to enable it I would do it.

The problem is that they have:

- a history of not being completely honest (unlike certain other actors who have a history of being actively dishonest)

- no easy way for people to choose what they send

- and a number of other problems, for example what I suspect is that they ignore actual users seemingly in favour of what their ux designers and developers think a user should want. (And that seems to always be dumbing down, "simplifying" and making it more like Chrome.)

This is mostly useless information since it has no context of what's going on, so can't really separate noise from signal. Much fewer user complains about cancellations due to various issues is more valuable.

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

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.

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!

Next bookmarks window resizing, well we can dream.

Reply on news.ycombinator.com