env: Force a separate Firefox profile #120
Conversation
Otherwise Firefox launched in the guest will concurrently access the host profile, corrupting it. We can make it not do that by implementing locks, which would fix the corruption but would still break the browser in the guest. So let's explicitly set a muvm-private Firefox profile. Signed-off-by: Asahi Lina <lina@asahilina.net>
hoshinolina
requested review from
WhatAmISupposedToPutHere,
alyssarosenzweig,
slp and
teohhanhui
as code owners
|
Firefox communicates over d-bus to connect to an existing instance, right? I think perhaps the right way to go is to forward that? Which IIUC will fix other things like some desktop integration too... |
|
Dbus forwarding would be nice to have, but it is more complicated than it looks (there is fd passing involved), and you would need to have a "dbus firewall", as we will want certain objects to be separate between host and guest. I would say it is a bit too much rn, and the solution above works. |
|
i was wondering about this. i run a nix home-manager firefox-esr to port my stuff over and each build corrupts the profile.ini file. my fix: to add a pre and posthook to backup and replace to keep the previous profile.ini to just keep the native firefox to work. curious if this works for the firefox-esr |
|
That sounds like a different issue, I think? It's not profile.ini that gets corrupted, it's the actual profile databases (the ones that go quickly are cookies and places (history)). This happens because the VM does not share locks with the host (yet), so the normal locking that Firefox does on the profile does not work. If you are running multiple Firefox instances without a filesystem or OS layer that makes locks not work across them, they should not be able to launch concurrently on the same profile. The environment variable probably works for all versions of Firefox though, if you want to try it. |
Worth noting that xdg-dbus-proxy does exist, motivated by similar goals within flatpak. |
6 participants
Otherwise Firefox launched in the guest will concurrently access the host profile, corrupting it. We can make it not do that by implementing locks, which would fix the corruption but would still break the browser in the guest. So let's explicitly set a muvm-private Firefox profile.