1820196 - Bundled language packs do not follow system Firefox updates

Status: UNCONFIRMED

(Toolkit :: Add-ons Manager, defect, P3)

Description

[maxim.cournoyer]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.8.0

Steps to reproduce:

On my Guix System system, the language packs are bundled with IceCat (Firefox), and IceCat honors the system-specified locale.

When the icecat package receives updates, (say, updating from version 102.7.0 to 102.8.0), the language pack currently in use is not updated along.

For the original context this bug was reported in, see: https://issues.guix.gnu.org/61914.

Actual results:

The language pack extension currently used stays at the same version, as can be seen in the "Complementary modules" table in about:support:

Estonian Language Pack	locale	102.8.0	true	[e-mail]
Finnish Language Pack	locale	102.8.0	true	[e-mail]
Français Language Pack	locale	102.7.0	true	[e-mail]
Frysk (fy) Language Pack	locale	102.8.0	true	[e-mail]
Gàidhlig Language Pack	locale	102.8.0	true	[e-mail]

There are multiple profile files keeping a reference to the now outdated extension, but it's been reporting that substituting the offending references from the following files:

~/.mozilla/icecat/<profile>/extensions.json \
~/.mozilla/icecat/<profile>/addonStartup.json.lz4

Is enough to fix the immediate problem.

On Guix, the problem is made worse by the stale language pack referenced possibly being garbage collected from the system, since they are no longer supposed to be in actual use. When this happens, the user interface becomes unusable, with all the translatable text showing blank.

Expected results:

All the language packs (whether in use or not) provided by the system should stay up to date. The user profile should not keep outdated references to potentially nonexistent language packs.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Untriaged' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Alex Cornestean]

Hello,

After multiple tries, I managed to install Guix System 1.4.0 on a VM and noticed it did not come bundled with IceCat.

Searching the web for IceCat, I only came up with a command to install IceCat via the terminal with guix install icecat which installed version 102.5.0 and that has no updates or any language packs.

Is there a better source or method to install the latest version of the browser or another one of my choosing?
Where do I get language packs since I did not manage to find any on gnuzilla.gnu.org where the “Find more add-ons” link in Addons Manager leads to?

Also, please excuse the line of questions. I’m not familiar with the OS or with the browser variant. Thank you !

I will continue to investigate and hopefully come up with some results.

Comment 3

[maxim.cournoyer]

Hi Alex,

Thanks for diving in this bug with a hands-on approach :-). guix install icecat is the right command to install the un-branded build of Firefox (and lightly customized) available in Guix. To get newer versions as well as the recently added language packs (which are bundled with icecat), you will need to run guix pull first, which updates Guix itself, including its package collection.

It could be useful to make this in 2 movements, to reproduce what I see. I'd suggest something like:

guix pull --commit=acf7d01fc39f863726a4034cb11071e4d46a7094        # first commit introducing language packs
hash guix
guix install icecat glibc-locales
LC_ALL=fr_CA.utf8 icecat         # user interface should be in French, icecat is at version 102.7.0 (IIRC)

guix pull    # go to the latest guix revision available
guix upgrade     # update guix installed packages, icecat should now be at version 102.8.0

And then visiting the about:support page, hopefully you see that the french language pack that was automatically "installed" when using it with an earlier IceCat version stuck around (was not updated).

Comment 4

[maxim.cournoyer]

Oof, there no longer is a substitutes (pre-built binaries) for icecat for commit acf7d01fc39f863726a4034cb11071e4d46a7094, so it needs to be built from source. That's probably not going to go smoothly for your VM setup (unless you gave it like 16 GiB of RAM :-)). It seems it's also already at version 102.8.0 for this commit, not 102.7.0 as I recalled. That shouldn't be a blocker to reproduce though, since same-version produce different output in Guix, so still the underlying icecat installation prefix (and that of its bundled language packs) would have changed, which hopefully should also trigger an add-ons update.

Comment 5

[Rob Wu [:robwu]]

Could you attach extensions.json and addonStartup.json.lz4 ?

Comment 6

[maxim.cournoyer]

Attachment: extensions.json

Comment 7

[maxim.cournoyer]

Attachment: addonStartup.json.lz4

Comment 8

[maxim.cournoyer]

Hi,

Here's a freshly tested/verified reproducer. It assumes you already have Guix installed, but its exact revision shouldn't matter, since the guix time-machine command is used.

pkill icecat
icecat_prefix=$(guix time-machine --commit=acf7d01fc39f863726a4034cb11071e4d46a7094 -- build icecat)
$icecat_prefix/bin/icecat --ProfileManager
# Create a new profile, e.g. 1820196-repro, and ensure the 'Use the selected profile without asking at startup" checkbox is checked.
# Close the profile manager dialog and launch it in the French Canadian locale (or one you can read :-)).
LC_ALL=fr_CA.utf8 $icecat_prefix/bin/icecat
# Close IceCat normally (Ctrl-Q) and count the prefix occurences:
grep -Fo "$icecat_prefix" ~/.mozilla/icecat/<profile>/extensions.json | wc -l 
# In my case, it returns 226 references.
# Now use a newer icecat build and check if the extensions in the profile were updated or not:
icecat_prefix_new=$(guix time-machine --commit=7bbeaa87e3796d56cc762dcfbc340f9be301d5f6 -- build icecat)
LC_ALL=fr_CA.utf8 $icecat_prefix_new/bin/icecat
# Close IceCat normally (Ctrl-Q) and count the prefix occurences:
grep -Fo "$icecat_prefix_new" ~/.mozilla/icecat/<profile>/extensions.json | wc -l 
# In my case, it returns 0.   Let's see if it kept references to the old icecat prefix:
grep -Fo "$icecat_prefix" ~/.mozilla/icecat/<profile>/extensions.json | wc -l 
# -> 226, so yes!

The version string between these two versions hasn't changed (102.8.0), but the binary and language pack locations is different. The ctime of the binaries is not useful as it's controlled to be reproducible by Guix (Epoch 1 I think, 1970 something). I'd argue that in such a situation, the safe thing to do is to update all the references in extensions.json and other places they are kept.

Now, if you want to test the degraded user experience that can result from this, you can run the newer IceCat in a Linux container, which will lack the stale language pack references:

guix time-machine --commit=7bbeaa87e3796d56cc762dcfbc340f9be301d5f6 -- shell --share=$XAUTHORITY -E '^(X|DISPLAY)' -CN icecat coreutils -- env LC_ALL=fr_CA.utf8 icecat

See the attached screenshot (icecat-blank.png) for the result, where the UI text is blank.

Comment 9

[maxim.cournoyer]

Attachment: icecat-blank.png

Firefox/IceCat running in a container lacking the stale language packs references kept in the user profile.

Comment 10

[Alex Cornestean]

Thank you for the help provided in Comment 3 and Comment 8 !

For some reason, during guix install icecat glibc-locales (from Comment 3) and/or icecat_prefix=$(guix time-machine --commit=acf7d01fc39f863726a4034cb11071e4d46a7094 -- build icecat) (from Comment 8) GUIX freezes.

Yesterday I was running the VM with 20GB storage and 10 GB of RAM when the freeze occurred and today I increased both storage and RAM to 40GB, 12 GB RAM respectively, with basically the same result of GUIX freezing sooner or later.

I’m going to attempt to reinstall the OS and try the steps from Comment 3/Comment 8 again as soon as possible.

Comment 11

[maxim.cournoyer]

Building Firefox from source is very intensive, as you must know already :-). This happens when there's no pre-built binary available from the substitute server (https://ci.gnu.guix.org being one). I believe that's the reason it "hangs" in the VM. The build probably requires more memory.

I've now ensured both versions are available from the main Guix substitute server, which should spare having to build it locally, if you've authorized substitutes at Guix installation time.

Let me know if that helps!

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:willdurand, could you have a look please?

For more information, please visit auto_nag documentation.