1653841 - Sideloaded langpack migrated from unpacked to packed fails to update

Status: NEW

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

Description

[Wolfgang Rosenauer [:wolfiR]]

Trying to summarize what we have observed in openSUSE Firefox builds. I think this is an issue in the Firefox codebase though.

General information:

• we ship langpacks as part of the Firefox build to pick up the system language from the user environment
• we used to ship them as directories instead of XPIs up to now for no direct reason
• because sideloading of addons is prevented meanwhile by default we were doing some changes in the packaging of the langpacks including allowing sideloaded langpacks in the build
• the relevant change here seems to be that we are now shipping XPIs in browser/extensions instead of directories containing the langpacks

After this change and people updating to that version with 78.0.2 many were not able to start Firefox anymore with an XML error:
<toolbarbutton id="UITourTooltipClose" class="close-icon"
--------------^

We found out that the reference to the langpacks in addonStartup.json.lz4 to the directories seems to cause the issue. Either removing addonStartup.json.lz4 or fixing the references fixes the issue.
The longer story can be seen here:
https://bugzilla.opensuse.org/show_bug.cgi?id=1174184

Comment 1

[Andrew Swan [:aswan]]

Can you clarify the issue? If I understand correctly, the problem only applies to existing profiles that previously used unpacked language packs (i.e., what you refer to as "directories" rather than xpi files). Is that correct? Where were the unpacked language packs located and how were they installed?

In any case, it appears that you've made two distinct changes:

• switching language packs from unpacked to xpi files
• switching from sideloading to "distribution addons" (xpi files in the browser/extensions subdirectory of the firefox distribution directory are called distribution addons and are copied into the profile on startup)

Assuming the old langpacks were sideloaded, the new versions shipped as distribution addons should take precedence over anything left over in a sideloaded location, so either the distribution addons aren't actually getting installed or there's some other bug.

As a first step, lets get confirmation on the question from the first paragraph...

Comment 2

[Wolfgang Rosenauer [:wolfiR]]

Yes, only existing profiles are affected (but not sure if all)

The unpacked language packs were also installed under browser/extensions so they are still installed at the same location.
We have not switched to distribution addons because we have not moved them to distribution/extensions.

---

From the downstream bugreport:
The error is probably caused by the fact that the old addonStartup.json.lz4 says
"path": "[e-mail]"
"rootURI": "file:///usr/lib64/firefox/browser/extensions/[e-mail]/"

but now it must be called:
"path": "[e-mail]"
"rootURI": "jar:file:///usr/lib64/firefox/browser/extensions/[e-mail]!/"

Comment 3

[Andrew Swan [:aswan]]

Thanks for the clarification, updating the summary.

Comment 4

[stefan]

I have found that FF opens up normally and using the existing profile only on the first use.
If I exit and restart again the bug appears as described.

I started FF with an old profile from 2019 and it worked normally. By comparing the
addonStartup.json.lz4 of the old profile and the one from the update I found no difference.

So to me it seems that FF is spoiling its profile when shuttung down. Each time I copy my
newest profile from version FF77 into FF78 FF will start normally.

Hope that helps ...
Stefan