1459575 - Sideload scans happen too late for language packs to take effect before restart

Status: RESOLVED WONTFIX

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

Description

[Martin Stránský [:stransky] (ni? me)]

When langpack is distributed as bundled with Firefox and it's installed as an extension during Firefox install, it's not used for first time.

It's because it's missing at addonStartup.json so this.sortBootstrappedAddons() at XPIProvider::startup() does not find it.

It affects linux distros which ships US Firefox + langpacks as extensions.

Comment 1

[Andrew Swan [:aswan]]

I'm a little confused by your "as extension" language, language packs use packaging that is similar to extensions, but they are handled differently.

In any case, we could use some more detail here.  Do you know if this is something that regressed recently?  In any case, we could use either specific steps to reproduce, or a detailed description of how your Linux distro handles bundles language packs.

Comment 2

[Martin Stránský [:stransky] (ni? me)]

I can reliably reproduce that on Firefox 59 and 60, I didn't try 58 and former. It's reliably reproductible at debug/unoptimized builds and not so very visible at optimized builds - looks like a kind of race condition.

There's a schematic description of what happens (at FF60):

Langpack (cs in this case) is loaded (pre-loaded) correctly at startup because and then used:

AddonManager::startup()
AddonManager::callProvider()
XPIProvider::startup()

this.sortBootstrappedAddons() returns aushelper and langpack-cs because those are at addonStartup.json:

callBootstrapMethod() = [e-mail] activeAddon = undefined
loadBootstrapScope aId = [e-mail] file = [xpconnect wrapped nsIFile @ 0x7fce279e7760 (native @ 0x7fce279e8640)]
startup()

callBootstrapMethod() = [e-mail] activeAddon = undefined
loadBootstrapScope aId = [e-mail] file = [xpconnect wrapped nsIFile @ 0x7fce279e7ee0 (native @ 0x7fce279ec340)]

Langpack.getBootstrapScope aId = [e-mail] file = [xpconnect wrapped nsIFile @ 0x7fce279e7ee0 (native @ 0x7fce279ec340)]
Langpack getBootstrapScope
Langpack startup
Extension registerSource = cs
registerSource(browser-langpack-cs-browser)
locale vailable(cs)

-- and CS langpacks is used by browser

but when langpack-cs is missing at addonStartup.json it looks like:

AddonManager::startup()
AddonManager::callProvider()
XPIProvider::startup()

this.sortBootstrappedAddons() returns aushelper only:

callBootstrapMethod() = [e-mail] activeAddon = undefined
loadBootstrapScope aId = [e-mail] file = [xpconnect wrapped nsIFile @ 0x7f64f2a12880 (native @ 0x7f64f2a49640)]

[...]

locales = en-US
L10nRegistry.registerSource(app)
registerSource(app)
locale vailable(en-US)

-- EN locale is choosen as a fallback (default) one.

[...] ~ 1-2 passes and then the langpack-cs is processed:


callBootstrapMethod() = [e-mail] activeAddon = undefined
loadBootstrapScope aId = [e-mail] file = [xpconnect wrapped nsIFile @ 0x7f64df8600a0 (native @ 0x7f64e29f9c40)]
Langpack.getBootstrapScope aId = [e-mail] file = [xpconnect wrapped nsIFile @ 0x7f64df8600a0 (native @ 0x7f64e29f9c40)]

Comment 3

[Andrew Swan [:aswan]]

Thanks, I should have asked more specific questions.
Where on disk is the language pack installed?  On the first run, how is the requested locale set?

Comment 4

[Mike Hommey [:glandium]]

FWIW, it works in Debian for 59. We're putting the langpacks in /usr/lib/firefox/browser/extensions

Comment 5

[Martin Stránský [:stransky] (ni? me)]

(In reply to Andrew Swan [:aswan] from comment #3)
> Thanks, I should have asked more specific questions.
> Where on disk is the language pack installed?  On the first run, how is the
> requested locale set?

locale is set by:

pref("intl.locale.matchOS",                 true);
pref("intl.locale.requested",               "");

and the selected langpack is installed at:

~/.mozilla/extensions/{ec8030f7-c20a-464f-9b0e-13a3a9e97384}/

We use that location to speed up starup time, so we copy only the selected langpack here.

Comment 6

[Zibi Braniecki [:zbraniecki][:gandalf]]

> pref("intl.locale.matchOS",                 true);
> pref("intl.locale.requested",               "");

This means that our language negotiation will look into OS locales to match. On Linux this makes us read uloc_getDefault [0] which reads the POSIX env LC_ALL/LANG/LOCALE.

My hypothesis is that when firefox is installed and the langpack is installed from the package and we start Firefox with a new profile, the langpack is registered too late after main UI picks locale from the ChromRegistry and load DTD resources from it.

Then AddonsManager populates startup cache so that on the consequitive start the langpack is registered earlier from the cache and ChromeRegistry sends the right locale to the main UI.


[0] https://searchfox.org/mozilla-central/source/intl/locale/gtk/OSPreferences_gtk.cpp#28

Comment 7

[Martin Stránský [:stransky] (ni? me)]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #6)
> > pref("intl.locale.matchOS",                 true);
> > pref("intl.locale.requested",               "");
> 
> This means that our language negotiation will look into OS locales to match.
> On Linux this makes us read uloc_getDefault [0] which reads the POSIX env
> LC_ALL/LANG/LOCALE.
> 
> My hypothesis is that when firefox is installed and the langpack is
> installed from the package and we start Firefox with a new profile, the
> langpack is registered too late after main UI picks locale from the
> ChromRegistry and load DTD resources from it.
> 
> Then AddonsManager populates startup cache so that on the consequitive start
> the langpack is registered earlier from the cache and ChromeRegistry sends
> the right locale to the main UI.
> 
> 
> [0]
> https://searchfox.org/mozilla-central/source/intl/locale/gtk/
> OSPreferences_gtk.cpp#28

Yes, I can confirm that the langpacks are loaded too late if they are missing in startup cache.

Comment 8

[Kris Maglione [:kmag]]

There are ways to work around this. The simplest ones are:

1) Move the add-ons to the distribution/ directory, which should be scanned at startup.
2) Set extensions.startupScanScopes to include the scopes that the langpacks are stored in.

Both of those have startup performance impacts, but there really isn't another option. The only way we can have new langpacks available at startup is to block startup to scan for and install them.

Given the above, I don't think there's anything for us to do platform-side here. If distributions need a startup side-load scan for their langpacks to work, they should make those config changes themselves. Otherwise we'll be penalizing users who don't need them.