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

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

[Mark H Weaver]

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 screenshots@mozilla.org.xpi) 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

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

[Andreas Enge]

Hello Mark,

On Fri, Sep 18, 2020 at 02:48:34AM -0400, Mark H Weaver wrote:
> 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.

thanks for this (very hidden) work-around. I confirm that it has worked
very well for me. And I would just like to mention a (not problematic)
caveat: "reset your addons" also includes removing additional add-ons
installed by the user.

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

So refreshing in the above sense should not be done without asking the
user first.

Andreas

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

[Mark H Weaver]

Hi Andreas,

Andreas Enge <andreas@enge.fr> writes:

> On Fri, Sep 18, 2020 at 02:48:34AM -0400, Mark H Weaver wrote:
>> 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.
>
> thanks for this (very hidden) work-around. I confirm that it has worked
> very well for me.

I'm glad to hear it!

> And I would just like to mention a (not problematic)
> caveat: "reset your addons" also includes removing additional add-ons
> installed by the user.

Yes, thanks for clarifying that point.

>> 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.
>
> So refreshing in the above sense should not be done without asking the
> user first.

Agreed.  When I wrote of implementing an "automatic refresh", I meant
something very different and much more limited than what "Refresh
IceCat" in <about:support> does: I meant merely to refresh the embedded
store names in the user profile to be valid again, without modifying any
user customizations.

Additionally, if a bundled extension was not explicitly disabled by the
user, but became nonfunctional due to this bug, I would like the
yet-to-written new code to do what is needed to make it functional
again.  Also, when IceCat is updated, any bundled extensions should be
automatically updated as well.  However, any bundled extensions that the
user explicitly disabled should stay disabled.

Does that make sense?

      Thanks!
        Mark

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

[Andreas Enge]

Hello Mark!

On Mon, Sep 21, 2020 at 01:53:36PM -0400, Mark H Weaver wrote:
> Agreed.  When I wrote of implementing an "automatic refresh", I meant
> something very different and much more limited than what "Refresh
> IceCat" in <about:support> does: I meant merely to refresh the embedded
> store names in the user profile to be valid again, without modifying any
> user customizations.
> 
> Additionally, if a bundled extension was not explicitly disabled by the
> user, but became nonfunctional due to this bug, I would like the
> yet-to-written new code to do what is needed to make it functional
> again.  Also, when IceCat is updated, any bundled extensions should be
> automatically updated as well.  However, any bundled extensions that the
> user explicitly disabled should stay disabled.
> 
> Does that make sense?

Definitely!

Andreas