Over in Bug 1721767, I observed that a firstrun of an MSIX-installed package is shockingly slow. I tracked it down to the Addon Manager installing the huge number of extensions (i.e., 125 langpacks in distribution/extensions) very slowly but I can't really speak to what's happening internally.

To test this, it should be enough to populate distributuions/extensions with lots of langpacks and then start with a fresh profile.

Zibi: I'm quite sure this is an Addon Manager thing, but it's a problem for the i18n team, so perhaps y'all could take a first look at this?

https://hg.mozilla.org/mozilla-central/rev/30288538de48

Comment on attachment 9238043 [details]
Bug 1726214 - For MSIX, install the addons in the corresponding language directory. r?mixedpuppy!,nalexander!

Beta/Release Uplift Approval Request

• User impact if declined: The plan of record is to publish MSIX packages for Firefox 93. These packages are like snap or flatpak packages: they include many langpacks (~100). These langpacks are processed at first-run, and with this many, the process is opaque and slow: it just looks like a hang before the window paints. These patches avoid this wretched experience.
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: The MSIX QA organization will be able to test this on Beta. Kaply has tested the distribution code in Nightly; I have tested the MSIX bits in Nightly as well, but it's hard to do so because Nightly signs langpacks differently than Beta and Release, in such a way that first run changes are not easy.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The distribution change is not risky because we're interesting new functionality not used by any existing consumer, and because it is tested. The MSIX packaging changes are not risky because nobody is consuming these MSIX packages yet.
• String changes made/needed:

https://hg.mozilla.org/mozilla-central/rev/a9f4f4c030e4

Comment on attachment 9242191 [details]
Bug 1726214 - Post: Create MSIX packages with langpacks in language-specific subdirectory. r?bhearsum!

Approved for 93 beta 9, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/a8b9dd00e750
https://hg.mozilla.org/releases/mozilla-beta/rev/2d7f438e5a02

Hello Nick! Can you please give us some detailed steps in order to verify this? From my understanding is that we need to copy lots of langpacks.xpi's inside C:\Program Files\WindowsApps\MozillaFoundation.MozillaFirefoxBeta_93.0.2.0_x64__1asrjg2sqer5r\VFS\ProgramFiles\Mozilla Firefox Beta Package Root\distribution\extensions. Is that correct? The only thing is that the extension folder is already populated with folders containing the associated langpack.xpi.
Also, I noticed that in about:addons page -> Languages there are only the languages that are installed inside Windows Settings. I know that on the builds before this fix all the langpacks were displayed inside about:addons. Thank you!

(In reply to Alexandru Trif, QA [:atrif] from comment #11)

Also, I noticed that in about:addons page -> Languages there are only the languages that are installed inside Windows Settings. I know that on the builds before this fix all the langpacks were displayed inside about:addons. Thank you!

This is the impact of this ticket and by design. What happens now is that on Firefox startup (every startup, not just first run) the set of Windows OS-locales is "matched" against the set of langpack locales and matching langpacks are installed. That prevents installing ~100 langpacks on first run, which is very slow. You should find (and I think you already have confirmed) that if you add a Windows OS locale and restart Firefox, you gain the corresponding langpack. (Langpacks are never removed; they'll just hang around if you remove Windows OS locales.)

Can you please give us some detailed steps in order to verify this? From my understanding is that we need to copy lots of langpacks.xpi's inside C:\Program Files\WindowsApps\MozillaFoundation.MozillaFirefoxBeta_93.0.2.0_x64__1asrjg2sqer5r\VFS\ProgramFiles\Mozilla Firefox Beta Package Root\distribution\extensions. Is that correct? The only thing is that the extension folder is already populated with folders containing the associated langpack.xpi.

Hello Alexandru! In fact, this should be much easier to test at this time. With the latest beta from this TH build, namely this x86-64 MSIX, you should be able to verify this just by installing. For me, I get the profile import succeeded dialog, a quick startup, and then in about:addons I have a subset of languages: en-CA, en-GB, es-ES, and sco. (Note: I have es-ES even though I have es-UY -- Spanish, Uruguay -- installed. That's the "matching" I described above.)

The difficulties testing this arise only for Nightly, which requires a preference to be set that can't be set early enough automatically: https://bugzilla.mozilla.org/show_bug.cgi?id=1721764.

Thank you, Nick! I verified the above scenario while installing the provided build 93.0b9 (20210923190449) on a clean environment and while having a .exe Firefox installed. All extensions inside C:\Program Files\WindowsApps\MozillaFoundation.MozillaFirefoxBeta_93.0.2.0_x64__1asrjg2sqer5r\VFS\ProgramFiles\Mozilla Firefox Beta Package Root\distribution\extensions are placed on individual folders. Firefox has a quick startup and inside about:addons-> Languages there are only the Languages installed on Windows displayed. Also installing a new Language inside Windows adds it inside add-ons after a restart or reopening. Removing one from Windows still keeps them inside about:addons as stated above.
Removing the qe+ flag since we can't test on Nightly due to bug 1721764.