Open Bug 1766756 Opened 4 years ago Updated 1 year ago

Some languages is not successfully removed in "Firefox Language Setting" window.

Categories

(Firefox :: Settings UI, defect, P3)

Firefox 99
Desktop
macOS
defect

Tracking

()

People

(Reporter: batman173895, Unassigned)

References

Details

Attachments

(1 file, 1 obsolete file)

Attached video Remove lanuage invalid —

[Affected versions]:

  • Firefox Release 99.0.1

[Affected Platforms]:

  • macOS 10.13.6

[Prerequisites]:

  • "Firefox Language Setting" window in "about:preferences" page have some more than 3 languages.

[Steps to reproduce]:

  1. Launch Firefox and access "about:preferences".
  2. Scoll down the page to "Language" Section.
  3. Click on the "Set Alternatives" Button, and "Firefox Language Setting" window pops up.
  4. Then remove some languages in "Firefox Language Setting" window.
  5. Click on "Apply and Restart" Button. Then Firefox Restart.
  6. Scoll down the page to "Language" Section and Click on the "Set Alternatives" Button again.
  7. Observe the "Firefox Language Setting" window.

[Expected result]:

  • Some languages has been removed.

[Actual result]:

  • No language is removed.

[Notes]:

  • The bug only happens in macOS 10.13.6.
  • I cannot reproduce this bug in Windows 10 and macOS 10.15.7.

Hey Greg, I seem to recall you've been hacking around in this space. Is this a about:preferences issue, or more of an issue with how language packs are stored and maintained?

Flags: needinfo?(gtatum)

I'm reproducing, and it appears to be some kind of issue with en-CA, as I'm not reproducing with fr. I suspect it's an about:preference logic issue.

Flags: needinfo?(gtatum)

This reproduces everywhere, as I can do it in nightly. There seems to be some logic issues between the Services.locale.requestedLocales and the final negotiated Services.locale.appLocaleAsBCP47.

Ok, I think this is what is going on.

That panel can only add language packs, and can't remove them. The language packs are still installed on the machine. You can see them in about:addons.

The panel sets the Services.locale.requestedLocales array, but the browser then negotiates on its own the ordering of which language packs to use. en-CA is determined to be a valid fallback of en-US, so it is retained in the negotiated app locales.

The panel loads in the app locales and not the requested locales, which means that en-CA will always be in the list as long as en-US is in the list, and the en-CA langpack is installed.

So what's being shown here is what the browser negotiated, not what the user requested.

Thanks for the deep-dive, gregtatum! What do you think makes the most sense as a solution - should we empower the dialog to actually remove the language packs? Or should we eliminate the "Remove" button, or something else?

Assignee: nobody → gtatum

I would suggest keeping the current behavior, but ensuring the the panel shows requested locales, rather than the negotiated locales. This only happens for "vertical fallbacking", where the region differs, but not the language. Making it work on requested locales would make the UI not confusing for users then. I do think some of the UX around this panel could be improved, but I think it would be good to keep this particular bug focused.

I have a patch up, but need a test for it.

Severity: -- → S3
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Assignee: gtatum → nobody
Status: ASSIGNED → NEW
Duplicate of this bug: 1847405

Windows also affected, please add to the bug platform field (if that is possible. Original report states Mac OS).

Attachment #9274318 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: