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

VERIFIED FIXED in Firefox 67

Status

()

defect
VERIFIED FIXED
20 days ago
6 days ago

People

(Reporter: robwu, Assigned: Gijs)

Tracking

(Blocks 1 bug, Regression, {regression})

64 Branch
Firefox 69
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr60 unaffected, firefox67+ verified, firefox67.0.5- wontfix, firefox68 verified, firefox69 verified)

Details

Attachments

(3 attachments)

Reporter

Description

20 days ago

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
Assignee

Comment 1

17 days ago

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

Flags: needinfo?(rob)
Flags: needinfo?(gandalf)
Reporter

Comment 2

17 days ago

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.

Assignee

Comment 3

16 days ago

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.

Flags: needinfo?(rob)
Reporter

Comment 5

16 days ago

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?

Flags: needinfo?(rob)
Assignee

Comment 6

16 days ago

(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.

Flags: needinfo?(rob)
Flags: needinfo?(pascalc)
Flags: needinfo?(lhenry)

Comment 7

16 days ago
Pushed by gijskruitbosch@gmail.com:
https://hg.mozilla.org/integration/autoland/rev/3b4847a2951e
make button state in browser language dialog correct when there's no available languages, r=johannh
Reporter

Comment 8

16 days ago

(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.

Reporter

Updated

16 days ago
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Flags: needinfo?(rob)
Reporter

Comment 9

16 days ago
Posted video bad.ogv

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

Reporter

Comment 10

16 days ago
Posted video good.ogv

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

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.

Flags: needinfo?(rob)
Flags: needinfo?(lhenry)
Flags: needinfo?(gijskruitbosch+bugs)
Reporter

Comment 12

16 days ago

(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/

Flags: needinfo?(rob)
Assignee

Updated

16 days ago
Flags: needinfo?(pascalc)
Flags: needinfo?(gijskruitbosch+bugs)

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

Assignee

Comment 14

16 days ago

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
Attachment #9068958 - Flags: approval-mozilla-release?
Attachment #9068958 - Flags: approval-mozilla-beta?
Assignee

Updated

16 days ago
Flags: qe-verify+

Comment 15

16 days ago
bugherder
Status: ASSIGNED → RESOLVED
Closed: 16 days ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 69
Flags: needinfo?(gandalf)
QA Whiteboard: [qa-triaged]

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

Status: RESOLVED → VERIFIED

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

Attachment #9068958 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

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

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.

Attachment #9068958 - Flags: approval-mozilla-release? → approval-mozilla-release+

Verified on 67.0.2 - build 2 as well.

Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.