Subject: bug#43487: icecat store names in user profiles break bundled addons

From: Mark H Weaver <[email-masked]>
Date: Fri, 18 Sep 2020 02:48:34 -0400

The Guix build of IceCat-68 stores absolute file names of the form
/gnu/store/…-icecat-68.…/* within user profiles in ~/.mozilla/icecat/*.

For example, ~/.mozilla/icecat/*/extensions.json contains store
references of the forms:
/gnu/store/…-icecat-68.…/lib/icecat/browser/features/*.xpi and
/gnu/store/…-icecat-68.…/lib/icecat/browser/extensions/*.xpi.

One effect is that IceCat's bundled extensions become non-functional
after the referenced /gnu/store/…-icecat-68.… store item is deleted.
This affects both the "builtin" extensions included in upstream Firefox
(e.g. formautofill@… and [email-masked]) as well as the
more visible bundled extensions such as LibreJS and HTTPS Everywhere.

One visual artifact is that the extension's buttons, that would normally
appear to the right of the URL bar, are missing their icons and are
therefore invisible, although if you hover over them they become
highlighted.

Creating a fresh profile will temporarily fix these problems, but only
until the next time "guix gc" deletes the 'icecat' store item
referenced.

To temporarily fix these problems while retaining most of your user
data, one option is to press the "Refresh IceCat…" button in
<about:support>.  Choosing this option will reset all your preferences
and addons to the IceCat defaults, but allows you to preserve the rest
of your data, including your bookmarks, browser history, cookies, saved
passwords, and your open tabs.

A proper fix will likely involve modifying the relevant code in IceCat
to either avoid storing the full file names in extensions.json, or else
to detect them on startup and automatically "refresh" them as needed.

I looked at the Nix package for Firefox, hoping that they might have
addressed this issue, but I found only one modification that looked
promising, namely their 'env_var_for_system_dir.patch' which adds
support for a MOZ_SYSTEM_DIR environment variable and sets the variable
in their wrapper.  I tried adding that to IceCat in Guix, but alas, it
did not help with this issue.  I guess that its purpose is to enable
other Nix packages to provide Firefox extensions.

This bug report is primarily about IceCat-68, where I've observed the
failure modes described above many times, and worked around it by
periodically "Refreshing IceCat" from <about:support>.  However,
IceCat-78 is affected by this issue as well, at least in part.
IceCat-78 also stores references to /gnu/store/…-icecat-78.…/* within
the user's profile, including in extensions.json.  However, I haven't
yet verified that the same failure mode occurs with its bundled
extensions, because I've not yet allowed any of my icecat-78 store items
to be reclaimed.  It's possible that the addition of
"--allow-addon-sideload" in Guix's IceCat 78 package might allow the
bundled extensions to refresh themselves automatically.

       Mark