1827573 - The title from the left part of the “Choose Your Language” screen is not translated, and the <OS Language> is missing from the primary button

Status: VERIFIED FIXED

(Firefox :: Messaging System, defect, P1)

Description

[Simona Rosu [:srosu], Ecosystem QA]

Attachment: FxApromptExp_ChooseYourLanguageSlide.gif

[Affected versions]:

• Firefox Beta 113.0b2 (Build ID: 20230411180038)

[Affected Platforms]:

• Windows 10 x64
• Windows 11 x64

[Prerequisites]:

• Have the Firefox Beta 113.0b2 en-US build installed and opened.
• Have set the Japanese OS language.
• Have the “nimbus.debug” pref set to true in the “about:config” page.

[Steps to reproduce]:

1. Force enroll in the Treatment B branch of the experiment using the following link: about:studies?optin_slug=prompt-fxa-creation-after-import&optin_branch=treatment-b&optin_collection=nimbus-preview
2. Navigate to the “about:welcome” page.
3. Click the “Save and continue” button from the first screen and complete the import flow.
4. Observe the elements from the “Choose Your Language” screen.

[Expected result]:

• The title from the left part of the screen and the label of the primary button are translated into Japanese.

[Actual result]:

• The title from the left part of the screen is not translated.
• The “Switch to” label of the primary button is displayed.

[Notes]:

• This issue is ONLY reproducible when being enrolled in the experiment.
• This issue is NOT reproducible on the Treatment A branch of the experiment.
• The elements of the “Choose Your Language” screen are correctly displayed after the page refresh.
• This issue is also reproducible when the German(Germany) OS language is set.
• This issue is also reproducible when naturally enrolled in the experiment.
• Attached is a screen recording of the issue.

Comment 1

[Emily McMinn :emcminn]

I wonder if this has to do with timing. When I reproduce the bug normally, the markup for the Primary button shows "negotiatedLanguage" as an empty string, which means window.AWNegotiateLangPackForLanguageMismatch hasn't had a chance to run yet and fetch the langPack. (See screenshot.) If I set a breakpoint and step through the screens with the debugger, the langpack and strings load correctly.

LanguageSwitcher is supposed to show a waiting screen with a spinner if the strings haven't loaded yet, so I suspect there's something going on with detecting the install status of the Langpack.

We're supposed to call AWEnsureLangPackInstalled, but setting a breakpoint there shows that function not getting hit until the page is refreshed.

Greg, any idea why this might be happening? (And why some langpacks would take longer to fetch than others?)

In terms of the experiment, an easy fix to unblock would be to remove the LanguageSwitcher screen. (Since the experiment should only be running on EN locales anyway.)

Comment 2

[Greg Tatum [:gregtatum]]

And why some langpacks would take longer to fetch than others?

The langpacks are fetched through AMO I believe, so it's a variable length network request. This means that things could have race conditions. The way I would test this locally when I originally wrote it is I would inject long timeouts randomly in the async functions. You might be able to make this reproduce every time.

Something like this:

await new Promise(resolve => setTimeout(resolve, 5000));

I know that thinking through the async problems and flow of the pages was hard to reason with. It might also need to wait on something in the l10n loading flow.

There is also the ready promise, which might need to be awaited for the langpacks after they are installed to ensure that the bundles are ready in them. I'm not 100% sure what all this promise is waiting on, so I"m not sure about the guarantees.

await document.l10n.ready;

https://searchfox.org/mozilla-central/search?q=await+document.l10n.ready%3B&path=&case=false&regexp=true

Comment 3

[Emily McMinn :emcminn]

After some investigation, it looks like the langpack is being installed correctly, triggering the "ready" screen to show, but for some reason there's a delay in setting the negotiatedLanguage prop on the page elements. (If there was no langpack, the preloading screen would show instead.) Bug 1796986 shows similar behaviour with "Switch to ${negotiatedLanguage}" showing on the button if the network connection is slow or disabled while the LanguageSwitcher is loading. I'm experimenting with adding some safeguards to make sure the prop is set before the screen renders.

Comment 4

[Punam Dahiya [:pdahiya]]

Issue reported in the bug looks like fallout of how dynamic targeting is implemented with https://bugzilla.mozilla.org/show_bug.cgi?id=1820566 that have special handling of evaluating targeting and setting screens state when action has isDynamic property set. This possibly caused uselanguageSwitcher to re-run again losing $negotiatedlanguage variable values

https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/browser/components/newtab/content-src/aboutwelcome/components/MultiStageAboutWelcome.jsx#378

https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/browser/components/newtab/content-src/aboutwelcome/components/MultiStageAboutWelcome.jsx#153

https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/browser/components/newtab/content-src/aboutwelcome/components/LanguageSwitcher.jsx#102

STR on MacOS local build:

1. Update AboutWelcomeDefaults.jsm screens property from gist here

2. Open Firefox instance by running below script:
   ./mach run --temp-profile --setpref "extensions.getAddons.langpacks.url=https://mock-amo-language-tools.glitch.me/?app=firefox&type=language&appversion=%VERSION%" --setpref "intl.multilingual.aboutWelcome.languageMismatchEnabled=true" --setpref "intl.multilingual.aboutWelcome.systemLocaleOverride=pt-BR"#(optional)-- --new-tab about:welcome

3. Click 'skip the step' secondary button on Easy Setup screen , shows language switcher screen primary button with negotiated language.

4. Hit back , click primary button CTA which has isDynamic property set to true, shows language switcher screen with missing negotiated language in primary button

Hit of refresh on language switcher screen shows primary button correct with negotiated language in label

Comment 5

[Ed Lee :Mardak]

(In reply to Punam Dahiya [:pdahiya] from comment #4)

https://searchfox.org/mozilla-central/rev/31f5847a4494b3646edabbdd7ea39cb88509afe2/browser/components/newtab/content-src/aboutwelcome/components/LanguageSwitcher.jsx#102

Seems like this behavior should be split out into a separate useEffect that watches for [screen, <result from AWEnsureLangPackInstalled>] so that a new screen changed by isDynamic gets updated without ensuring lang pack is installed duplicate/multiple times.

Comment 6

[Emily McMinn :emcminn]

I've updated the experiment recipe to remove the LanguageSwitcher screen & unblock it for 113 Beta; we have a fix for this that can ride the trains to 114.

Comment 7

[Emily McMinn :emcminn]

Attachment: Bug 1827573 - Separate installphase useEffect from langPackContent

Comment 8

[Punam Dahiya [:pdahiya]]

Should be addressed with fix of https://bugzilla.mozilla.org/show_bug.cgi?id=1823779

Comment 9

[Punam Dahiya [:pdahiya]]

Fixed with https://bugzilla.mozilla.org/show_bug.cgi?id=1823779 in Fx114

Comment 10

[Alice Varro [avarro], Ecosystem QA]

I have verified this issue using the latest Firefox Release 114.0.1, en-US locale (Build ID: 20230608214645) on Windows 10 x64 and Windows 11 x64. By following the steps from the description I can confirm the following:

• The title from the left part of the "Choose your language" slide is translated using Japanese or German OS language.
• The string from the primary button of the "Choose your language" screen is successfully translated in the OS language.