Closed Bug 1626593 Opened 4 years ago Closed 4 years ago

Arabic Firefox mirrored if locale is set to en-US even if language is still Arabic

Categories

(Firefox :: Distributions, defect, P3)

All
Windows
defect

Tracking

()

RESOLVED INVALID
Tracking Status
firefox75 --- wontfix

People

(Reporter: obotisan, Assigned: mkaply)

Details

(Keywords: regression)

Attachments

(4 files)

Attached file distribution.zip

Affected platforms

  • Windows 10 x64
  • Windows 8.1 x86

Prerequisites:

  • Run the commands in CMD as admin:
    rd /s /q %userprofile%\AppData\Roaming\Mozilla
    rd /s /q %userprofile%\AppData\Local\Mozilla
    rd /s /q %userprofile%\AppData\LocalLow\Mozilla
  • Download an older build than Firefox 72.0 with the locale "ar" and the language pack for this build (ar.xpi).
  • Copy the distribution folder that is attached to this bug in the Firefox folder.
  • Remove the English language pack from the C:....\distribution\extensions directory and replace is with the ar.xpi under the name "langpack-ar@firefox.mozilla.org.xpi".

Steps to reproduce

  1. Update the browser manually (Menu -> Help -> About Firefox -> Restart to update Firefox).
  2. Repeat step 1 and pay attention to the orientation of the navigation toolbar.

Expected result

    1. The browser updates to 72.0.2 and the browser looks as expected.
    1. The browser updates to 75.0 and the browser looks as expected.

Actual result

    1. The browser updates to 72.0.2 and the browser looks as expected.
    1. The browser updates to 75.0 and the browser has the navigation toolbar is mirrored.

Additional notes

  • This issue is happening only if the distribution.ini has these prefs:
    general.useragent.locale="en-US"
    intl.locale.requested="en-US"
  • If those prefs are changed to "ar" the issue is not reproducing anymore.
  • This issue is reproducing if the initial Firefox is newer than 72.0, too.

We shouldn't be using the Arabic locale with en-US information in the distribution.ini, should we?

If the locale is ar, intl.locale.requested and general.useragent.locale should also be ar.

Mike, could you set the priority flag? Also, is it affecting 76?

Flags: needinfo?(mozilla)

I'm not able to recreate this.

I followed the exact steps above.

At any point was the browser in Arabic (It shouldn't be because the prefs are en-US)

Can you post a screenshot?

Flags: needinfo?(mozilla) → needinfo?(oana.botisan)
Priority: -- → P3
Attached image acer build.gif

I did the update from 70.0.2 to the latest release.

Flags: needinfo?(oana.botisan)

I guess I'm confused.

You said:

This issue is happening only if the distribution.ini has these prefs:
general.useragent.locale="en-US"
intl.locale.requested="en-US"

But your UI is in Arabic before the upgrade which means those values must be "ar"?

I feel like there's a step missing here. How did your UI get to Arabic in the first place?

I just follow the steps from comment 0. I did nothing else.

I found the problem here and it's unrelated to Acer.

The problem is that if you set the locale to en-US on an Arabic build, even if that build is still Arabic language, we switch the UI to LTR.

I don't think we should not switch the UI to LTR if there is no en-US locale actually installed.

To recreate, use this distrbution.ini:

[Global]
id=generic
version=1.0
about=Mozilla Firefox

[Preferences]
intl.locale.requested="en-US"

There are probably simpler ways to recreate this.

Zibi: This apparently is a recent change. Any ideas?

Flags: needinfo?(gandalf)
Summary: [Acer distribution] UI mirrored if updating AR build without changing the distribution.ini language prefs → Arabic Firefox mirrored if locale is set to en-US even if language is still Arabic

The problem is that if you set the locale to en-US on an Arabic build, even if that build is still Arabic language, we switch the UI to LTR.

I don't understand the STR here.

If you switch locale during runtime, you have to restart the browser. What does "if you set the locale to en-US" mean then?

Flags: needinfo?(gandalf)

If you switch locale during runtime, you have to restart the browser. What does "if you set the locale to en-US" mean then?

Using distrbution.ini, you can preset the locale so it's set at first startup.

Previously, having this locale set to en-US had no effect on an Arabic build. For some reason it's changed, so that setting an en-US locale for an Arabic build (en-US not installed) causes the UI to go LTR.

Can you share the the about:support bottom section for Localization & Internationalization?

Flags: needinfo?(mozilla)
Flags: needinfo?(mozilla)

Previously you said:

The problem is that if you set the locale to en-US on an Arabic build, even if that build is still Arabic language, we switch the UI to LTR.

But from the screenshot it looks like the locale chain is ["en-US", "ar"], so the locale is, in fact, en-US, and the LTR is the right directionality for it. What am I missing?

But from the screenshot it looks like the locale chain is ["en-US", "ar"], so the locale is, in fact, en-US, and the LTR is the right directionality for it. What am I missing?

Did something change recently to allow locales in the locale chain that aren't available in Firefox?

en-US is not installed, but it allowed as the app locale and causes the LTR change even though the text of the UI is still in Arabic.

Based on what test is saying, this didn't used to be the case. In the past, the en-US was ignored because it wasn't an installed locale.

I'll go back and verify what they are seeing on older versions of Firefox.

The only thing that comes to mind happened in 2017 - introduction of Fluent which bundles last fallback locale (en-US) as a fallback for other locales, which means that when you use any locale, you do have en-US available.

In the future, we'll start building more complex chanins of locales and multi-locale langpacks, so relying on a lack of available locale to determine the preferred locale is not future proof.
If you don't want en-US, you should not have en-US as the first in requested.

Firefox 70 has the exact same content in about:support, but the UI is not switched to LTR.

So something definitely regressed here...

So something definitely regressed here...

Since the negotiated locale is en-US, the app bidi should be LTR. If anything, something improved and some code relied on the broken behavior :)

The only changes I can find is either bug 1597822 which improved bidi for pseudo in 72 and bug 1616999 which landed in 75.

As I said in comment 14, I don't think any code should be in the state where the top negotiated locale is en-US and expect the bidi to show RTL.

I don't disagree, but I still think it's worthwhile knowing exactly what caused the change to make sure it was on purpose :).

Last good build was:
https://hg.mozilla.org/mozilla-central/rev/e2e130df4e969b6dea71288ee6c617c9bf0e2a98
First bad was
https://hg.mozilla.org/mozilla-central/rev/acc0c8327c266ac0b0c61eecdba6d625957ecf81

which is:

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=e2e130df4e969b6dea71288ee6c617c9bf0e2a98&tochange=acc0c8327c266ac0b0c61eecdba6d625957ecf81

Which i think points to:

Use AppLocale to set document direction for chrome, about and resource protcols.
https://bugzilla.mozilla.org/show_bug.cgi?id=1614767

Ah, that's one more bug that was a response to RTL inconsistencies. Without it, we were inconsistent in reporting directionality in the scenario reported here.
We would likely report LTR from LocaleService, and RTL from ChromeRegistry - that's because ChromeRegistry only saw ar locales from DTD, while LocaleService saw both en-US and ar locales and had the unified negotiated status.

So should I close this as working as designed? OR dupe to that bug?

Yes, working as designed as per:

Additional notes

    This issue is happening only if the distribution.ini has these prefs:
    general.useragent.locale="en-US"
    intl.locale.requested="en-US"

Closing as working as designed. en-US shouldn't be used for intl.locale.requested if the en-US locale isn't installed.

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.