Chromium-based "installed apps" (PWA) sometimes accidentally garbage collected

Using NixOS with Home-manager (unstable channel). One little pain point I have right now is that these websites that advertise themselves are installable apps (I am using Brave but the same applies to most chromium browsers I suppose) are sometimes removed by what I think is the nix garbage collector.

Is it a known issue? I’d like to prevent that from happening. I guess these installable apps are little beyond a handful of resource files + symlinks stored something in $HOME, yet they are perceived at some point as dead symlinks and thus gc’ed.

Any clue appreciated…

IDK but can you reproduce the problem or this is your guess about gc ?

Installable webapps are not symlinks and don’t store any local resources, they are just .desktop files that start your browser with specific flags.

The nix garbage collector only touches paths in /nix/store, anyway, not random symlinks lying around everywhere on your system, there’s no way it would delete things from your home directory.

There’s something else going on here.

I see that the .desktop files are there sitting on ~/Desktop (an callable from brave://apps) but that I can no longer call them using the GNOME app launcher. (this thing:

) and when invoked from brave://apps they are considered by Alt-tab as mere browser windows (they no longer have their own icon).

Since the app launcher makes use of .desktop it founds in various places, my hunch was that the .desktop files it uses for my installable apps are gc’ed, in which case they probably were symlinks to the original files sitting in ~/Desktop.

If this is incorrect, what else could be the culprit?

Sounds to me like whatever variable added ~/Desktop to the set of directories GNOME will look for .desktop files in changed.

By default, it’s supposed to look in ~/.local/share/applications - or specifically, I think all applications subdirectories of the directories in $XDG_DATA_DIRS and $XDG_DATA_HOME, which defaults to ~/.local/share and some system paths that users shouldn’t normally write to.

This usually happens because the program creating the desktop file in ~/.local/share/applications uses an absolute path to itself in the Exec field of the desktop file and the old path is eventually garbage collected. The only solution is to patch the app to avoid using absolute paths like we did with Flatpak: Flatpak exports point towards a binary in the nix store, breaking on flatpak updates. · Issue #156664 · NixOS/nixpkgs · GitHub

Thanks a lot for the explanation! I have not contributed to Nix but that looks like a low effort / high reward PR.

Looks like there is an issue here: Chromium: installed app won't launch · Issue #150826 · NixOS/nixpkgs · GitHub

Creating the patch should not require much effort but testing the patch might be not be so easy – Chromium is PITA to build.

I am looking into this. Here’s a .desktop file from one of these PWAs installed through Brave:

Exec=/nix/store/qw0yx6qgnkg5r8az93lhmcqpaagjskiy-brave-1.60.118/opt/ --profile-directory=Default --app-id=pjibgclleladliembfgfagdaldikeohf

So you’re saying that instead of /nix/store/... the Exec= line should use a relative path?

Not relative, it should be literally:

Exec=brave-browser --profile-directory=Default --app-id=pjibgclleladliembfgfagdaldikeohf

This is because when nix updates an application, its path in the nix store will get a new hash. So when you update your system, this .desktop would need to be updated to point to the new brave - but it is not, since nix is not aware of it.

That then means that when you open that .desktop you launch an older version of brave.

I believe it still “works” - but shows up as an empty application with no icon - because the old version has not yet been garbage collected, but browsers use an API to open additional webpages in an already running instance of themdelves. Or perhaps the icon for this binary is simply no longer on your system post update.

Either way, you don’t want to be using the old brave, so you should set the browser to be looked up in your path. That way whatever browser is currently installed will be used, and not some potentially outdated or completely absent one.

Thanks, I’ll try to your workaround! But do you agree that this is worth a lilttle patch?

I do, and having now actually read the issue, I don’t really think upstream can fix this without breaking other use cases (like not having chromium on $PATH at all), so the patch suggested in the issue is not just appropriate but necessary.

It’ll break ssb things for people who don’t add chromium to their path, but those were already going to break eventually anyway.