Some languages is not successfully removed in "Firefox Language Setting" window.
Categories
(Firefox :: Settings UI, defect, P3)
Tracking
()
People
(Reporter: batman173895, Unassigned)
References
Details
Attachments
(1 file, 1 obsolete file)
|
3.65 MB,
video/quicktime
|
Details |
[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]:
- Launch Firefox and access "about:preferences".
- Scoll down the page to "Language" Section.
- Click on the "Set Alternatives" Button, and "Firefox Language Setting" window pops up.
- Then remove some languages in "Firefox Language Setting" window.
- Click on "Apply and Restart" Button. Then Firefox Restart.
- Scoll down the page to "Language" Section and Click on the "Set Alternatives" Button again.
- 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.
Comment 1•4 years ago
|
||
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?
Comment 2•4 years ago
|
||
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.
Comment 3•4 years ago
|
||
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.
Comment 4•4 years ago
|
||
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.
Comment 5•4 years ago
|
||
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?
Updated•4 years ago
|
Comment 6•4 years ago
|
||
Comment 7•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•3 years ago
|
Comment 9•3 years ago
|
||
Windows also affected, please add to the bug platform field (if that is possible. Original report states Mac OS).
Updated•1 year ago
|
Description
•