1554744 - Cannot add a new language pack via the preferences UI if getAvailableLocales returns an empty list

Status: VERIFIED FIXED

(Firefox :: Settings UI, defect)

Description

[Rob Wu [:robwu]]

If getAvailableLocales returns an empty list (this happens in practice due to bug 1554742), then the "Firefox Language Settings" view at about:preferences is unusable. In particular, when the "Select a language to add" dropdown is clicked, no languages are shown (so it is not possible to add a new language).

STR:

1. Visit about:config and set intl.multilingual.enabled and intl.multilingual.downloadEnabled to true (this is the default on Release and Beta, not on Nightly).
2. Visit about:preferences
3. Open the JS console of the tab and run getAvailableLocales = async () => []
4. Click on the "Language" dropdown, and select "Search for more languages"
5. Click on the "Select a language to add" dropdown.

Expected:

• Lots of languages to choose from.

Actual:

• Nothing happens. The global JS console shows the following error:

TypeError: this.selectedItem is undefined browserLanguages.js:83:47

Comment 1

[:Gijs (out for now; he/him)]

Which branches are affected by this in practice? Does it make sense to fix separately from bug 1554742?

Comment 2

[Rob Wu [:robwu]]

I added bug 1506102 in the "regressed by" field, which landed in Firefox 66.
I confirm that the feature works as intended in Firefox 65.0.3, so this is a recent regression and worth fixing separately if bug 1554742 cannot quickly be fixed (note that this other regression bug started in Firefox 60 at bug 1431260; going unnoticed for 6 releases may indicate that "properly" fixing that other bug has a low risk).

And FWIW, the language selection UI was enabled by default in Firefox 64 at bug 1493711.

Comment 3

[:Gijs (out for now; he/him)]

Doesn't the "language" dropdown in the main preferences page also break (ie have no language entry for the current lang) if there's no current language? This doesn't happen in the STR from comment #0 because there's a language when the page first loads...

That is, I can come up with a trivial patch for the dialog but I'm wondering if that really unbreaks things in the "real" case where this reproduces.

Comment 4

[:Gijs (out for now; he/him)]

Attachment: Bug 1554744 - make button state in browser language dialog correct when there's no available languages, r?jaws

Comment 5

[Rob Wu [:robwu]]

The patch does work. When I put a breakpoint on getAvailableLocales, and patch the method by assigning your proposed method to OrderedListBox.prototype.setButtonState, then I get a meaningful dropdown from where I can add new languages.

After adding a language (e.g. en-US), the dropdown works even without the patch (because the language set is no longer empty).

Could we try to get this simple patch in Firefox 67.0.1?

Comment 6

[:Gijs (out for now; he/him)]

(In reply to Rob Wu [:robwu] from comment #5)

The patch does work. When I put a breakpoint on getAvailableLocales, and patch the method by assigning your proposed method to OrderedListBox.prototype.setButtonState, then I get a meaningful dropdown from where I can add new languages.

I didn't mean this dropdown, I meant the one on the main prefs page. For me, on a local build, it initially lists en-US, but if I understand correctly, if the APIs here are broken, wouldn't it list nothing? That's certainly what happens for me after the patch on nightly if I accept the dialog without adding any languages.

[Tracking Requested - why for this release]:

Could we try to get this simple patch in Firefox 67.0.1?

I don't know, pinging Pascal/Liz. It'd probably help if you elaborated on impact (the other bug seems to be mentioning distro builds?) and what you think the complete behaviour pre/post patch is on actually affected builds.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3b4847a2951e
make button state in browser language dialog correct when there's no available languages, r=johannh

Comment 8

[Rob Wu [:robwu]]

(In reply to :Gijs (he/him) from comment #6)

(In reply to Rob Wu [:robwu] from comment #5)

The patch does work. When I put a breakpoint on getAvailableLocales, and patch the method by assigning your proposed method to OrderedListBox.prototype.setButtonState, then I get a meaningful dropdown from where I can add new languages.

I didn't mean this dropdown, I meant the one on the main prefs page. For me, on a local build, it initially lists en-US, but if I understand correctly, if the APIs here are broken, wouldn't it list nothing? That's certainly what happens for me after the patch on nightly if I accept the dialog without adding any languages.

The initial value in the main view is empty, but that is not the problem here (to me, as a user).
I will attach videos where the difference is more obvious.

[Tracking Requested - why for this release]:

Could we try to get this simple patch in Firefox 67.0.1?

I don't know, pinging Pascal/Liz. It'd probably help if you elaborated on impact (the other bug seems to be mentioning distro builds?) and what you think the complete behaviour pre/post patch is on actually affected builds.

Our official releases have updaters, so they are not affected by bug 1554742, and hence not affected by this bug.
This bug mainly affects distro builds and other custom builds where the updater is disabled.

Comment 9

[Rob Wu [:robwu]]

Attachment: bad.ogv

Video showing broken language selection dropdown, using Firefox 67.0 from ArchLinux.

Comment 10

[Rob Wu [:robwu]]

Attachment: good.ogv

Video showing working language pack selection dropdown, using Firefox 67.0 from https://www.mozilla.org/en-US/firefox/

Comment 11

[Liz Henry (:lizzard) (relman/hg->git project)]

Does this have a particularly bad impact on users with the Trailhead release? If not, then I'd prefer that we defer the fix to a 67.0.2.

Comment 12

[Rob Wu [:robwu]]

(In reply to Liz Henry (:lizzard) (use needinfo) from comment #11)

Does this have a particularly bad impact on users with the Trailhead release? If not, then I'd prefer that we defer the fix to a 67.0.2.

It does not. This bug does not affect our official Firefox releases.

I asked for an uplift to release because the patch is very low risk, and fixes a regression in 66. Distro packagers are likely following our release schedule, so if the patch bcomes part of the next release, then this patch will automatically reach distros.

67.0.2 is okay though, because users could work around this bug by not using about:preferences, but manually search and install a langpack via https://addons.mozilla.org/firefox/language-tools/

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

OK, thanks, if you come up with a fix please request uplift and we can likely get it into 67.0.2.

Comment 14

[:Gijs (out for now; he/him)]

Comment on attachment 9068958 [details]
Bug 1554744 - make button state in browser language dialog correct when there's no available languages, r?jaws

Beta/Release Uplift Approval Request

• User impact if declined: Distro users can't easily install/use additional/different languages using the built-in preferences UI
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment #0
• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Tiny JS-only patch that changes some logic about when we disable buttons to avoid JS errors
• String changes made/needed: none

Comment 15

[Arthur Iakab [arthur_iakab]]

https://hg.mozilla.org/mozilla-central/rev/3b4847a2951e

Comment 16

[Cristian Fogel [:cfogel]]

Issue confirmed wtih 68.0b6.
Fix verified with 69.0a1 (2019-06-02) on Windows 10, macOS 10.13, Ubuntu 18.04.

Comment 17

[Julien Cristau [:jcristau]]

Comment on attachment 9068958 [details]
Bug 1554744 - make button state in browser language dialog correct when there's no available languages, r?jaws

approved for 68.0b7

Comment 18

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/releases/mozilla-beta/rev/fa85a070d833

Comment 19

[Cristian Fogel [:cfogel]]

Verified with 68.0b7 on Windows 10, macOS 10.13, Ubuntu 18.04.

Comment 20

[Pascal Chevrel:pascalc]

Comment on attachment 9068958 [details]
Bug 1554744 - make button state in browser language dialog correct when there's no available languages, r?jaws

Simple patch verified this week in Beta, approved for 67.0.2, thanks.

Comment 21

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-release/rev/a3f533043261

Comment 22

[Cristian Fogel [:cfogel]]

Verified on 67.0.2 - build 2 as well.