2046945 - Widgets doesn't match UI locale after switching language from settings

Status: VERIFIED FIXED

(Firefox :: New Tab Page, defect)

Description

[Francesco Lodolo [:flod]]

Use Firefox Release and make sure the World Cup widget is enabled. In my case, the build is in Italian.

Go to Settings and switch language, e.g. to German. The widget remains in Italian, restarting the browser doesn't update it.

Comment 1

[Francesco Lodolo [:flod]]

Attachment: Screenshot 2026-06-11 alle 22.04.31.png

Sadly widgets seem to be all over the place.

I have some widgets partially in German and Italian (Checklist). World Clock shows tooltips in Italian. World Cup widget is in Italian. Time seems to be in German.

Comment 2

[Francesco Lodolo [:flod]]

[Tracking Requested - why for this release]: this is a very poor experience for users switching language at run-time, which includes MSIX builds and most Linux distro.

Comment 3

[Francesco Lodolo [:flod]]

I've tested a local build (using these instructions to change locale) and it seems to behave correctly.

I'm starting to think that the problem might be with the train-hop code? Is there a way to verify that, e.g. use the built-in version?

I think I've also seen New Tab settings being half-translated at some point, but can't replicate.

Comment 4

[Francesco Lodolo [:flod]]

In my release build, the New Tab XPI is at version 153.3.20260605.21338 (from browser.newtabpage.trainhopAddon.version).

unzip -p [e-mail] locales/locales-report.json \
  | python3 -c 'import json,sys; r=json.load(sys.stdin); \
    print("snapshot:", r["meta"]["updated"]); \
    m=r["locales"]["de"].get("missing",{}); \
    print("de missing:", sorted(i for v in m.values() for i in v))'
snapshot: 2026-06-04T19:16:58.548047
de missing: ['newtab-sports-widget-match-vs', 'newtab-sports-widget-no-upcoming-matches', 'newtab-sports-widget-team-tbd']

For example, the checklist add button label is in there.

Comment 5

[Francesco Lodolo [:flod]]

This is the result of me spending way too much time digging through this bug with Claude. Leaving it for HNT engineers to evaluate if it makes any sense.

• The "newtab" Fluent source is registered only on the XPI path and asynchronously: registerFluentSources awaits fetch("/locales/supported-locales.json") before calling _updateFluentSourcesRegistration.
• Content processes get Fluent sources synchronously at init (RegisterFileSourcesFromParentProcess), plus runtime updates via L10nRegistrySendUpdateL10nFileSources. But a content document's DOMLocalization only re-translates on intl:app-locales-changed — not when a source-update IPC arrives.
• So about:newtab / about:home renders before that source is wired into the content document, and nothing re-translates it when the source shows up. newtab strings then resolve only from the langpack/omnijar: strings present there render fine, while train-hop-only / re-keyed strings keep their baked-in default or fall back through.

Evidence: in the parent process, new Localization(["browser/newtab/newtab.ftl"]).formatValue("newtab-widget-lists-button-add-item") returns the correct German — the registry is complete; only the content document is missing the source.

Possible fix: register the "newtab" source before content renders (read supported-locales.json synchronously instead of await fetch), and re-translate open about:newtab / about:home documents after _updateFluentSourcesRegistration (both initial and on locale change).

Comment 6

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

The bug is marked as tracked for firefox152 (beta) and tracked for firefox153 (nightly). However, the bug still isn't assigned.

:thecount, could you please find an assignee for this tracked bug? If you disagree with the tracking decision, please talk with the release managers.

For more information, please visit BugBot documentation.

Comment 7

[sfield]

@maxx can we get a fix for this in the next trainhop?

Comment 8

[Mike Conley (:mconley) (:⚙️)]

Hey Stephen,

I've started poking at this one, and at this point, I'm fairly convinced that it requires changes in the base application, and cannot be fixed with a trainhop. This means that, given where we are in the release cycle, a fix for this (assuming I can get one crafted in the next day or so) will be available in the first dot release of 152 (June 23rd, so a week tomorrow).

If there is sufficient urgency and user impact here, we could talk to RelMan about an out-of-band dot release, but I believe the weekly dot releases mean that the bar for out-of-band dot releases is much higher than it used to be.

Comment 9

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1: Fire intl:l10n-sources-changed when L10nRegistry sources mutate r?#platform-i18n-reviewers!

Long-lived Localization instances cache the bundles they generate on first
use. Until now, no observer notification fired when sources were registered,
updated, or removed in L10nRegistry, so those caches were never invalidated;
any source registered after startup (e.g. by AboutNewTabResourceMapping when
a train-hopped newtab XPI is active) was invisible to already-translated
documents.

We introduce a new intl:l10n-sources-changed observer topic, fired by
L10nRegistry in both the parent (L10nRegistrySendUpdateL10nFileSources) and
content (RegisterFileSourcesFromParentProcess) processes after the registry
has been mutated. Localization::Observe now listens for it and drops cached
bundles, mirroring its existing handling of intl:app-locales-changed.

A dedicated topic is used rather than reusing intl:app-locales-changed so
the ~30 other observers that care only about negotiated-locale changes
(font list, mozIntl caches, sidebar, tabbrowser, …) aren't woken on every
source mutation.

Comment 10

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 2: Expose active langpack ids and a webextension-langpack-shutdown observer topic r?robwu!

Consumers of L10nRegistry that want to register sources alongside a
langpack's (for example, to provide a locale-specific override for an
individual resource) need two things this module didn't previously
provide: an authoritative enumeration of currently-active langpacks at
the time the consumer initializes, and lifecycle notifications symmetric
to the existing webextension-langpack-startup topic.

We add a static Langpack.activeLangpackIds Set, mutated at the same
callsites that mutate the L10nRegistry, exposing the langpack metasource
strings (startupData.langpackId, which is not the addon's id). We then
fire a new webextension-langpack-shutdown observer topic before the langpack
removes its L10nRegistry sources, so consumers can clean up parallel
registrations in the same metasource before it goes away.

The first consumer in AboutNewTabResourceMapping in the next patch in this
series.

Comment 11

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 3: Register newtab XPI Fluent source into each active langpack's metasource r?#home-newtab-reviewers!

The L10nRegistry solver builds bundles atomically per (locale, metasource):
so every required resource must be satisfiable from sources in that
metasource for that locale, or no bundle is produced.

The "app" metasource's non-newtab sources (toolkit, browser) are packaged en-US
only, so with a non-English langpack the (locale, "app") bundle can never be
built — and the train-hop newtab XPI's locale-specific strings are
unreachable, falling through to en-US. That is why train-hop-only widget
strings (added to the XPI but not yet present in any langpack) were
rendering in the wrong language.

We make AboutNewTabResourceMapping also register a shadow newtab
L10nFileSource into each active langpack's metasource, enumerated via
Langpack.activeLangpackIds and kept in sync with
webextension-langpack-startup/-shutdown observer notifications). Within the
(locale, langpack) bundle, the solver now yields two valid orderings: one
with the langpack's older newtab.ftl, one with the XPI's. Fluent falls
through the former on missing keys and resolves train-hop-only strings
from the latter, while strings the langpack already translates continue
to come from the langpack.

Comment 12

[Mike Conley (:mconley) (:⚙️)]

Attachment: Unsigned en-ES-langpack.xpi for manual testing

Comment 13

[Mike Conley (:mconley) (:⚙️)]

Attachment: Unsigned [e-mail] with mconley-test test string

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/1f508514efb9
https://hg.mozilla.org/integration/autoland/rev/d747305f99fb
Part 1: Fire intl:l10n-sources-changed when L10nRegistry sources mutate r=eemeli
https://github.com/mozilla-firefox/firefox/commit/b2cb45cec4a4
https://hg.mozilla.org/integration/autoland/rev/695da3586cfe
Part 2: Expose active langpack ids and a webextension-langpack-shutdown observer topic r=robwu
https://github.com/mozilla-firefox/firefox/commit/c063096fa111
https://hg.mozilla.org/integration/autoland/rev/5e620d8e172d
Part 3: Register newtab XPI Fluent source into each active langpack's metasource r=maxx

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ca1fcfd2f0af
https://hg.mozilla.org/integration/autoland/rev/a2f41ceb0459
Revert "Bug 2046945 - Part 3: Register newtab XPI Fluent source into each active langpack's metasource r=maxx" for causing failures at test_ext_permissions.js.

Comment 16

[Atila Butkovits]

Backed out for causing failures at test_ext_permissions.js.

Backout link: https://hg.mozilla.org/integration/autoland/rev/a2f41ceb0459

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=5e620d8e172d19dd07a081055c4dec907000ab3d

Failure logs:
https://treeherder.mozilla.org/logviewer?job_id=573244656&repo=autoland&task=RQnHW5-YTfOKkncp0xaYMw.0&lineNumber=14801
https://treeherder.mozilla.org/logviewer?job_id=573245712&repo=autoland&task=HDNxFAylTfqPIvy7KVwwTg.0&lineNumber=15312

Comment 17

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1.5: Have AboutNewTabChild retrigger translation of about:newtab on intl:l10n-sources-changed. r?#home-newtab-reviewers!

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/18a6410b0f69
https://hg.mozilla.org/integration/autoland/rev/b402dd4a5458
Revert "Bug 2046945 - Part 3: Register newtab XPI Fluent source into each active langpack's metasource. r=maxx" for causing xpcshells and TV-nofis failures at l10nregistry_observer.js

Comment 19

[Silaghi Andreea]

Backed out for causing xpcshells and TV-nofis failures at l10nregistry_observer.js
Backout Link
Push with failures
Failure Log
Failure line TEST-UNEXPECTED-FAIL | intl/l10n/test/test_l10nregistry_observer.js | test_localization_invalidates_on_topic - [test_localization_invalidates_on_topic : 110] After intl:l10n-sources-changed, Localization picks up the updated source - "before" == "after"

Comment 20

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/70f3b13322b3
https://hg.mozilla.org/integration/autoland/rev/4cdfcf1ffba7
Part 1: Fire intl:l10n-sources-changed when L10nRegistry sources mutate. r=eemeli
https://github.com/mozilla-firefox/firefox/commit/311beab6bed5
https://hg.mozilla.org/integration/autoland/rev/6b0730c30744
Part 1.5: Have AboutNewTabChild retrigger translation of about:newtab on intl:l10n-sources-changed. r=maxx
https://github.com/mozilla-firefox/firefox/commit/450693f9e4f1
https://hg.mozilla.org/integration/autoland/rev/203fbb945a56
Part 2: Expose active langpack ids and a webextension-langpack-shutdown observer topic. r=robwu
https://github.com/mozilla-firefox/firefox/commit/454f00b7c4b5
https://hg.mozilla.org/integration/autoland/rev/3e5c4b170c49
Part 3: Register newtab XPI Fluent source into each active langpack's metasource. r=maxx

Comment 21

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1: Fire intl:l10n-sources-changed when L10nRegistry sources mutate

Long-lived Localization instances cache the bundles they generate on first
use. Until now, no observer notification fired when sources were registered,
updated, or removed in L10nRegistry, so those caches were never invalidated;
any source registered after startup (e.g. by AboutNewTabResourceMapping when
a train-hopped newtab XPI is active) was invisible to already-translated
documents.

We introduce a new intl:l10n-sources-changed observer topic, fired by
L10nRegistry in both the parent (L10nRegistrySendUpdateL10nFileSources) and
content (RegisterFileSourcesFromParentProcess) processes after the registry
has been mutated. Localization::Observe now listens for it and drops cached
bundles, mirroring its existing handling of intl:app-locales-changed.

A dedicated topic is used rather than reusing intl:app-locales-changed so
the ~30 other observers that care only about negotiated-locale changes
(font list, mozIntl caches, sidebar, tabbrowser, …) aren't woken on every
source mutation.

Comment 22

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1.5: Have AboutNewTabChild retrigger translation of about:newtab on intl:l10n-sources-changed.

Comment 23

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 2: Expose active langpack ids and a webextension-langpack-shutdown observer topic

Consumers of L10nRegistry that want to register sources alongside a
langpack's (for example, to provide a locale-specific override for an
individual resource) need two things this module didn't previously
provide: an authoritative enumeration of currently-active langpacks at
the time the consumer initializes, and lifecycle notifications symmetric
to the existing webextension-langpack-startup topic.

We add a static Langpack.activeLangpackIds Set, mutated at the same
callsites that mutate the L10nRegistry, exposing the langpack metasource
strings (startupData.langpackId, which is not the addon's id). We then
fire a new webextension-langpack-shutdown observer topic before the langpack
removes its L10nRegistry sources, so consumers can clean up parallel
registrations in the same metasource before it goes away.

The first consumer in AboutNewTabResourceMapping in the next patch in this
series.

Comment 24

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Users with non-en-US langpacks installed (So non-en-US users on MSIX on Windows, Linux) may find some of their New Tab UI isn't localized properly, and is falling back to en-US.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Ensure that New Tab 153.5.20260615.213953 is installed. This may require you to force enroll in https://experimenter.services.mozilla.com/nimbus/new-tab-153520260615213953-to-release-152-wcw-v4/summary/.

Install an alternative langpack for release or beta, and ensure that recent strings are available in the relevant locale.

Then, in New Tab, open up the devtools console, and paste / execute this command:

(await document.l10n.formatMessages(["home-homepage-title"]))[0].attributes[0].value

and ensure that a string is returned ("Homepage" in en-US, but something appropriate for the installed langpack).

• Risk associated with taking this patch: low
• Explanation of risk level: This set of patches includes unit tests, and while it's scary that it has C++ changes, those changes really just add an observer notification that only the New Tab listens to. Same with the extensions change, which just exposes some things for New Tab to listen to. So really, the blast radius is restricted to New Tab - and I'm fairly confident we've got this right.
• String changes made/needed?: None.
• Is Android affected?: no

Comment 25

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 3: Register newtab XPI Fluent source into each active langpack's metasource

The L10nRegistry solver builds bundles atomically per (locale, metasource):
so every required resource must be satisfiable from sources in that
metasource for that locale, or no bundle is produced.

The "app" metasource's non-newtab sources (toolkit, browser) are packaged en-US
only, so with a non-English langpack the (locale, "app") bundle can never be
built — and the train-hop newtab XPI's locale-specific strings are
unreachable, falling through to en-US. That is why train-hop-only widget
strings (added to the XPI but not yet present in any langpack) were
rendering in the wrong language.

We make AboutNewTabResourceMapping also register a shadow newtab
L10nFileSource into each active langpack's metasource, enumerated via
Langpack.activeLangpackIds and kept in sync with
webextension-langpack-startup/-shutdown observer notifications). Within the
(locale, langpack) bundle, the solver now yields two valid orderings: one
with the langpack's older newtab.ftl, one with the XPI's. Fluent falls
through the former on missing keys and resolves train-hop-only strings
from the latter, while strings the langpack already translates continue
to come from the langpack.

Comment 26

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1: Fire intl:l10n-sources-changed when L10nRegistry sources mutate

Long-lived Localization instances cache the bundles they generate on first
use. Until now, no observer notification fired when sources were registered,
updated, or removed in L10nRegistry, so those caches were never invalidated;
any source registered after startup (e.g. by AboutNewTabResourceMapping when
a train-hopped newtab XPI is active) was invisible to already-translated
documents.

We introduce a new intl:l10n-sources-changed observer topic, fired by
L10nRegistry in both the parent (L10nRegistrySendUpdateL10nFileSources) and
content (RegisterFileSourcesFromParentProcess) processes after the registry
has been mutated. Localization::Observe now listens for it and drops cached
bundles, mirroring its existing handling of intl:app-locales-changed.

A dedicated topic is used rather than reusing intl:app-locales-changed so
the ~30 other observers that care only about negotiated-locale changes
(font list, mozIntl caches, sidebar, tabbrowser, …) aren't woken on every
source mutation.

Comment 27

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1.5: Have AboutNewTabChild retrigger translation of about:newtab on intl:l10n-sources-changed.

Comment 28

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 2: Expose active langpack ids and a webextension-langpack-shutdown observer topic

Consumers of L10nRegistry that want to register sources alongside a
langpack's (for example, to provide a locale-specific override for an
individual resource) need two things this module didn't previously
provide: an authoritative enumeration of currently-active langpacks at
the time the consumer initializes, and lifecycle notifications symmetric
to the existing webextension-langpack-startup topic.

We add a static Langpack.activeLangpackIds Set, mutated at the same
callsites that mutate the L10nRegistry, exposing the langpack metasource
strings (startupData.langpackId, which is not the addon's id). We then
fire a new webextension-langpack-shutdown observer topic before the langpack
removes its L10nRegistry sources, so consumers can clean up parallel
registrations in the same metasource before it goes away.

The first consumer in AboutNewTabResourceMapping in the next patch in this
series.

Comment 29

[Phabricator Automation]

firefox-release Uplift Approval Request

• User impact if declined/Reason for urgency: Users with non-en-US langpacks installed (So non-en-US users on MSIX on Windows, Linux) may find some of their New Tab UI isn't localized properly, and is falling back to en-US.
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Ensure that New Tab 153.5.20260615.213953 is installed. This may require you to force enroll in https://experimenter.services.mozilla.com/nimbus/new-tab-153520260615213953-to-release-152-wcw-v4/summary/.

Install an alternative langpack for release or beta, and ensure that recent strings are available in the relevant locale.

Then, in New Tab, open up the devtools console, and paste / execute this command:

(await document.l10n.formatMessages(["home-homepage-title"]))[0].attributes[0].value

and ensure that a string is returned ("Homepage" in en-US, but something appropriate for the installed langpack).

• Risk associated with taking this patch: low
• Explanation of risk level: This set of patches includes unit tests, and while it's scary that it has C++ changes, those changes really just add an observer notification that only the New Tab listens to. Same with the extensions change, which just exposes some things for New Tab to listen to. So really, the blast radius is restricted to New Tab - and I'm fairly confident we've got this right.
• String changes made/needed?: None.
• Is Android affected?: no

Comment 30

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 3: Register newtab XPI Fluent source into each active langpack's metasource

The L10nRegistry solver builds bundles atomically per (locale, metasource):
so every required resource must be satisfiable from sources in that
metasource for that locale, or no bundle is produced.

The "app" metasource's non-newtab sources (toolkit, browser) are packaged en-US
only, so with a non-English langpack the (locale, "app") bundle can never be
built — and the train-hop newtab XPI's locale-specific strings are
unreachable, falling through to en-US. That is why train-hop-only widget
strings (added to the XPI but not yet present in any langpack) were
rendering in the wrong language.

We make AboutNewTabResourceMapping also register a shadow newtab
L10nFileSource into each active langpack's metasource, enumerated via
Langpack.activeLangpackIds and kept in sync with
webextension-langpack-startup/-shutdown observer notifications). Within the
(locale, langpack) bundle, the solver now yields two valid orderings: one
with the langpack's older newtab.ftl, one with the XPI's. Fluent falls
through the former on missing keys and resolves train-hop-only strings
from the latter, while strings the langpack already translates continue
to come from the langpack.

Comment 31

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/e8d3b69d5807
https://hg.mozilla.org/releases/mozilla-beta/rev/0634577e7457
https://github.com/mozilla-firefox/firefox/commit/97c0d86585ff
https://hg.mozilla.org/releases/mozilla-beta/rev/010bdc17c438
https://github.com/mozilla-firefox/firefox/commit/f8b390e0422a
https://hg.mozilla.org/releases/mozilla-beta/rev/f3860d719548
https://github.com/mozilla-firefox/firefox/commit/f6884c6e8e31
https://hg.mozilla.org/releases/mozilla-beta/rev/659b4c0b12ff

Comment 32

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/a8357417b619
https://hg.mozilla.org/releases/mozilla-release/rev/e0db870e5b55
https://github.com/mozilla-firefox/firefox/commit/7bb6cdd51bd3
https://hg.mozilla.org/releases/mozilla-release/rev/9fa3d6e7e84d
https://github.com/mozilla-firefox/firefox/commit/6c28283203d0
https://hg.mozilla.org/releases/mozilla-release/rev/027e00898fd0
https://github.com/mozilla-firefox/firefox/commit/d128e3eb1bb7
https://hg.mozilla.org/releases/mozilla-release/rev/d5468141b61c

Comment 33

[Dianna Smith [:diannaS]]

Rolled back from beta and release for causing xpc failures

Note this passed in autoland.
Claude says:
The difference is the locale packaging of the build under test, not the code:

• autoland / central: Android GeckoView test builds are single-locale en-US. Available locales is trivially {en-US}. Registering an en-US source → recomputed list is still {en-US} → no change → topic doesn't fire → PASS.
• beta / release: Android GeckoView is built multi-locale (it ships all the shipping locales). Available locales is a large list. Registering/removing a source perturbs the recomputed list (membership and/or ordering) enough that SetAvailableLocales sees a difference, re-negotiates, and the negotiated set changes → intl:app-locales-changed fires → assertion !fired is false → FAIL.

Comment 34

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/1d42c5900fd3
https://hg.mozilla.org/releases/mozilla-beta/rev/b83be8058db0
https://github.com/mozilla-firefox/firefox/commit/e17e1402437a
https://hg.mozilla.org/releases/mozilla-beta/rev/b69143ed53eb
https://github.com/mozilla-firefox/firefox/commit/b213ec5c4803
https://hg.mozilla.org/releases/mozilla-beta/rev/8ba2b00199c4
https://github.com/mozilla-firefox/firefox/commit/b4cb74fbe019
https://hg.mozilla.org/releases/mozilla-beta/rev/07149107d6bb

Comment 35

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/0d360509ceb9
https://hg.mozilla.org/releases/mozilla-release/rev/5995ce485e85
https://github.com/mozilla-firefox/firefox/commit/24df63f0774c
https://hg.mozilla.org/releases/mozilla-release/rev/62826a0fd662
https://github.com/mozilla-firefox/firefox/commit/3e17a6a7ebdf
https://hg.mozilla.org/releases/mozilla-release/rev/f5f2cd9ae647
https://github.com/mozilla-firefox/firefox/commit/e3c843bd2704
https://hg.mozilla.org/releases/mozilla-release/rev/3d9034d074ad

Comment 36

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/17b0783f75b7
https://hg.mozilla.org/mozilla-central/rev/896e001153ff
Part 1: Fire intl:l10n-sources-changed when L10nRegistry sources mutate. r=eemeli
https://github.com/mozilla-firefox/firefox/commit/4f43c549a840
https://hg.mozilla.org/mozilla-central/rev/0d14db284fc2
Part 1.5: Have AboutNewTabChild retrigger translation of about:newtab on intl:l10n-sources-changed. r=maxx
https://github.com/mozilla-firefox/firefox/commit/f1c5a3c77480
https://hg.mozilla.org/mozilla-central/rev/828a785c733d
Part 2: Expose active langpack ids and a webextension-langpack-shutdown observer topic. r=robwu

Comment 37

[rperta]

https://hg.mozilla.org/mozilla-central/rev/4cdfcf1ffba7
https://hg.mozilla.org/mozilla-central/rev/6b0730c30744
https://hg.mozilla.org/mozilla-central/rev/203fbb945a56
https://hg.mozilla.org/mozilla-central/rev/3e5c4b170c49

Comment 38

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Remove platform-fragile test_topic_separation_from_app_locales_changed r?eemeli!

The test asserted that registering an L10nFileSource with a locale
already in availableLocales would not fire intl:app-locales-changed.
But L10nRegistry::getAvailableLocales builds its result from a Rust
HashSet, whose iteration order is platform-randomized, and
LocaleService::SetAvailableLocales compares as an order-sensitive
nsTArray, so a no-op-for-the-set registration can still cascade
through LocalesChanged on platforms where the order differs
(reproducibly on Android shippable).

This was a belt-and-suspenders test I added for the first iteration of
the patches for bug 2046945, when we were having Localization.cpp flush
its internal notion of bundles when the sources changed. Since we're
no longer doing that, this test is just getting in the way.

Comment 39

[Phabricator Automation]

Comment on attachment 9599062 [details]
Bug 2046945 - Remove platform-fragile test_topic_separation_from_app_locales_changed r?eemeli!

Revision D307673 was moved to bug 2048663. Setting attachment 9599062 [details] to obsolete.

Comment 40

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1: Fire intl:l10n-sources-changed when L10nRegistry sources mutate

Long-lived Localization instances cache the bundles they generate on first
use. Until now, no observer notification fired when sources were registered,
updated, or removed in L10nRegistry, so those caches were never invalidated;
any source registered after startup (e.g. by AboutNewTabResourceMapping when
a train-hopped newtab XPI is active) was invisible to already-translated
documents.

We introduce a new intl:l10n-sources-changed observer topic, fired by
L10nRegistry in both the parent (L10nRegistrySendUpdateL10nFileSources) and
content (RegisterFileSourcesFromParentProcess) processes after the registry
has been mutated. Localization::Observe now listens for it and drops cached
bundles, mirroring its existing handling of intl:app-locales-changed.

A dedicated topic is used rather than reusing intl:app-locales-changed so
the ~30 other observers that care only about negotiated-locale changes
(font list, mozIntl caches, sidebar, tabbrowser, …) aren't woken on every
source mutation.

Comment 41

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1.5: Have AboutNewTabChild retrigger translation of about:newtab on intl:l10n-sources-changed.

Comment 42

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 2: Expose active langpack ids and a webextension-langpack-shutdown observer topic

Consumers of L10nRegistry that want to register sources alongside a
langpack's (for example, to provide a locale-specific override for an
individual resource) need two things this module didn't previously
provide: an authoritative enumeration of currently-active langpacks at
the time the consumer initializes, and lifecycle notifications symmetric
to the existing webextension-langpack-startup topic.

We add a static Langpack.activeLangpackIds Set, mutated at the same
callsites that mutate the L10nRegistry, exposing the langpack metasource
strings (startupData.langpackId, which is not the addon's id). We then
fire a new webextension-langpack-shutdown observer topic before the langpack
removes its L10nRegistry sources, so consumers can clean up parallel
registrations in the same metasource before it goes away.

The first consumer in AboutNewTabResourceMapping in the next patch in this
series.

Comment 43

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 3: Register newtab XPI Fluent source into each active langpack's metasource

The L10nRegistry solver builds bundles atomically per (locale, metasource):
so every required resource must be satisfiable from sources in that
metasource for that locale, or no bundle is produced.

The "app" metasource's non-newtab sources (toolkit, browser) are packaged en-US
only, so with a non-English langpack the (locale, "app") bundle can never be
built — and the train-hop newtab XPI's locale-specific strings are
unreachable, falling through to en-US. That is why train-hop-only widget
strings (added to the XPI but not yet present in any langpack) were
rendering in the wrong language.

We make AboutNewTabResourceMapping also register a shadow newtab
L10nFileSource into each active langpack's metasource, enumerated via
Langpack.activeLangpackIds and kept in sync with
webextension-langpack-startup/-shutdown observer notifications). Within the
(locale, langpack) bundle, the solver now yields two valid orderings: one
with the langpack's older newtab.ftl, one with the XPI's. Fluent falls
through the former on missing keys and resolves train-hop-only strings
from the latter, while strings the langpack already translates continue
to come from the langpack.

Comment 44

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1: Fire intl:l10n-sources-changed when L10nRegistry sources mutate

Long-lived Localization instances cache the bundles they generate on first
use. Until now, no observer notification fired when sources were registered,
updated, or removed in L10nRegistry, so those caches were never invalidated;
any source registered after startup (e.g. by AboutNewTabResourceMapping when
a train-hopped newtab XPI is active) was invisible to already-translated
documents.

We introduce a new intl:l10n-sources-changed observer topic, fired by
L10nRegistry in both the parent (L10nRegistrySendUpdateL10nFileSources) and
content (RegisterFileSourcesFromParentProcess) processes after the registry
has been mutated. Localization::Observe now listens for it and drops cached
bundles, mirroring its existing handling of intl:app-locales-changed.

A dedicated topic is used rather than reusing intl:app-locales-changed so
the ~30 other observers that care only about negotiated-locale changes
(font list, mozIntl caches, sidebar, tabbrowser, …) aren't woken on every
source mutation.

Comment 45

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 1.5: Have AboutNewTabChild retrigger translation of about:newtab on intl:l10n-sources-changed.

Comment 46

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 2: Expose active langpack ids and a webextension-langpack-shutdown observer topic

Consumers of L10nRegistry that want to register sources alongside a
langpack's (for example, to provide a locale-specific override for an
individual resource) need two things this module didn't previously
provide: an authoritative enumeration of currently-active langpacks at
the time the consumer initializes, and lifecycle notifications symmetric
to the existing webextension-langpack-startup topic.

We add a static Langpack.activeLangpackIds Set, mutated at the same
callsites that mutate the L10nRegistry, exposing the langpack metasource
strings (startupData.langpackId, which is not the addon's id). We then
fire a new webextension-langpack-shutdown observer topic before the langpack
removes its L10nRegistry sources, so consumers can clean up parallel
registrations in the same metasource before it goes away.

The first consumer in AboutNewTabResourceMapping in the next patch in this
series.

Comment 47

[Mike Conley (:mconley) (:⚙️)]

Attachment: Bug 2046945 - Part 3: Register newtab XPI Fluent source into each active langpack's metasource

The L10nRegistry solver builds bundles atomically per (locale, metasource):
so every required resource must be satisfiable from sources in that
metasource for that locale, or no bundle is produced.

The "app" metasource's non-newtab sources (toolkit, browser) are packaged en-US
only, so with a non-English langpack the (locale, "app") bundle can never be
built — and the train-hop newtab XPI's locale-specific strings are
unreachable, falling through to en-US. That is why train-hop-only widget
strings (added to the XPI but not yet present in any langpack) were
rendering in the wrong language.

We make AboutNewTabResourceMapping also register a shadow newtab
L10nFileSource into each active langpack's metasource, enumerated via
Langpack.activeLangpackIds and kept in sync with
webextension-langpack-startup/-shutdown observer notifications). Within the
(locale, langpack) bundle, the solver now yields two valid orderings: one
with the langpack's older newtab.ftl, one with the XPI's. Fluent falls
through the former on missing keys and resolves train-hop-only strings
from the latter, while strings the langpack already translates continue
to come from the langpack.

Comment 48

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/b2a5f4828268
https://hg.mozilla.org/releases/mozilla-beta/rev/4de228bdec9d
https://github.com/mozilla-firefox/firefox/commit/32ba8eec3a96
https://hg.mozilla.org/releases/mozilla-beta/rev/f9c681470792
https://github.com/mozilla-firefox/firefox/commit/05829d0f16c8
https://hg.mozilla.org/releases/mozilla-beta/rev/125c257102d4
https://github.com/mozilla-firefox/firefox/commit/492645606a46
https://hg.mozilla.org/releases/mozilla-beta/rev/d088524499f1

Comment 49

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/bbad1560212d
https://hg.mozilla.org/releases/mozilla-release/rev/fffa50ff8253
https://github.com/mozilla-firefox/firefox/commit/e9d6ace8317f
https://hg.mozilla.org/releases/mozilla-release/rev/70f2f358fb4b
https://github.com/mozilla-firefox/firefox/commit/ccb1b1d52d90
https://hg.mozilla.org/releases/mozilla-release/rev/26c023a20b4c
https://github.com/mozilla-firefox/firefox/commit/0cb19a868f2c
https://hg.mozilla.org/releases/mozilla-release/rev/b6359eb13fd1

Comment 50

[Ryan VanderMeulen [:RyanVM]]

Added to the 152.0.2 relnotes.

Comment 51

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Verified that this is fixed on Firefox 152.0.2, Firefox 153.0b3 and Firefox 154.0a1 (2026-06-21) by following the info provided in Comment 29. Tests were performed on macOS 26.5.1, Windows 11 and Ubuntu 26.04.