Closed Bug 1379910 Opened 7 years ago Closed 4 years ago

Add Preferences option to change the locale strategy for regional preferences

Categories

(Firefox :: Settings UI, enhancement, P5)

Product:
Firefox
Component:
Settings UI
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 77
Tracking Flags:
Tracking Status
firefox77 --- fixed

People

(Reporter: zbraniecki, Assigned: aarushivij, Mentored)

References

Details

(Keywords: good-first-bug)

Attachments

(3 files, 1 obsolete file)

Add preferences option for use system locale v2
4.51 KB, patch
zbraniecki
: feedback+
jaws
: feedback+
Details | Diff | Splinter Review
region.png
29.75 KB, image/png
Details
Bug 1379910 - Add Preference option to change the locale strategy for regional preferences r=zbraniecki
47 bytes, text/x-phabricator-request
Details | Review 
Based on the conversation in bug 1366134 I'd like to introduce a selector between two sources of locales for regional preferences.

The primary method is to follow the app locale set (so, Firefox in en-US, dates in en-US), but the alternative option is to follow OS locale set (so, Firefox in en-US, but Windows in de, and date formats for de).

In bug 1379420 I'm adding the API, and I'd like to add an option in Firefox Preferences for selecting between those two locales.

I believe that this would be a beginning of more detailed set of options related to intl/l10n which has been started in bug 1325870 and would cover a sortable list of UI locales (including downloading them), content locales and possibly regional preferences locales.

For now, all I'd like to suggest is a single switch that is enabled/displayed only when SystemLocale is different from AppLocale:

[ ] Use System Locale (ab-CD) for Regional Preferences.

The option is unchecked by default.
I'm not sure which pane this should go to as I imagine that with more options we'll eventually want to have a whole section or even a whole pane for Intl/L10n, but maybe for now it's probably under General > Languages.

:phlsa - are you the right person to evaluate the proposal and give a UX go/no-go?
Flags: needinfo?(philipp)
Depends on: 1379420
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #1)
> ... but maybe for now it's probably under General > Languages.
Can you please clarify: Do you intend to create "General > Languages" since there isn't one right now, or do you mean "Content > Languages"? But this choice relates to chrome, not content.
(In reply to Jorg K (GMT+2) from comment #2)
> Can you please clarify: Do you intend to create "General > Languages" since
> there isn't one right now, or do you mean "Content > Languages"? But this
> choice relates to chrome, not content.

In the new Preferences organization (Nightly and so on) there's General > Languages.
Anything beyond that will follow decisions that will be made in bug 1325870.
Sorry, I should have checked a Nightly before commenting here.
Mentor: gandalf
Keywords: good-first-bug
Priority: -- → P5
I believe this patch should do what is being suggested here:)
Attachment #8961658 - Flags: review?(gandalf)
As you can see in comment #5, Thunderbird uses different wording. IMHO "Use System Locale (%S) for Regional Preferences." is not correct. The system locale, as least on Windows, is different from the locale selected in Regional Preferences. Besides, the System Locale is not used for Regional Preferences. The user has a choice between using the Application Locale, that is the language the browser is compiled in, and the locale from Regional Settings.
Oh okay, I gotcha. Should we use radio buttons like they have in Thunderbird, or would a checkbox with "use locale from Regional Settings: %S" suffice?
Also, it looks like the option in Thunderbird is always visible. Currently, I have this option only visible if the application locale and regional settings locale don't match. Should we follow Thunderbirds lead here as well and make the option always visible?
> Should we use radio buttons like they have in Thunderbird, or would a checkbox with "use locale from Regional Settings: %S" suffice?

I'd prefer either a checkbox or a dropdown.

> Also, it looks like the option in Thunderbird is always visible. Currently, I have this option only visible if the application locale and regional settings locale don't match.

I prefer it to be hidden unless the conditions are met.

Thanks for the patch! I'll take a look at it today and will CC someone from the Preferences or UX to verify :)
Personally I'd say the TB isn't doing a fantastic job. It would be better to have a checkbox "use locale from Regional Settings: %S" when there is a choice.
Comment on attachment 8961658 [details] [diff] [review]
Add preferences option for use system locale

Review of attachment 8961658 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for the patch! A couple of suggestions for how to improve the code hopefully easy to apply :)

::: browser/components/preferences/in-content/main.js
@@ +875,5 @@
> +
> +    var appLocaleName = isc.getDictionaryDisplayName(appLocale);
> +    var systemLocaleName = isc.getDictionaryDisplayName(systemLocale);
> +
> +    if (appLocaleName != systemLocaleName) {

It would be better if you compared the locale codes and only if they match imported the inline spell check to get the dictionary display name of the OS locale.

::: browser/locales/en-US/browser/preferences/preferences.ftl
@@ +217,5 @@
>  
> +# LOCALIZATION NOTE (use-system-locale): Do not translate the word "%S" below.
> +# Place the word "%S" in your translation where the name of the locale should appear.
> +use-system-locale =
> +    .label = Use System Locale (%S) for Regional Preferences.

In FTL we don't use the `LOCALIZATION NOTE` part, because it is the only kind :)

Also, we don't use `%S`, instead you pass an argument, like this:

```
# Variables:
#    $localeName {string} - Localized name of the locale to be used.
use-system-locale =	
    .label = Use System Locale ({ $localeName }) for Regional Preferences.
```

and in JS you'll need to do:

```
document.l10n.setAttributes(elem, "use-system-locale", {localeName});
```
Attachment #8961658 - Flags: review?(gandalf) → review-
I think I've gotten all these changes made now, but I wanted to verify one thing before posting the updated patch. Should locale tags like en-US and en-US-u-va-posix be evaluated as equivalent?
Flags: needinfo?(gandalf)
> Should locale tags like en-US and en-US-u-va-posix be evaluated as equivalent?

In the perfect world yes. We don't have a good locale matching API yet in JS (we have one in C++!). I think that you can do a cutoff on "-u-" and remove everything there and match the rest.

If you do, add a comment with a link to bug 1349377 to get a better fix once we have the API. Thnx!
Flags: needinfo?(gandalf)
Thanks for the feedback! Here's another patch
Attachment #8961658 - Attachment is obsolete: true
Attachment #8962485 - Flags: review?(gandalf)
Comment on attachment 8962485 [details] [diff] [review]
Add preferences option for use system locale v2

Review of attachment 8962485 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/preferences/in-content/main.js
@@ +867,5 @@
> +
> +    var systemLocale =
> +      Components.classes["@mozilla.org/intl/ospreferences;1"]
> +                .getService(Components.interfaces.mozIOSPreferences)
> +                .getRegionalPrefsLocales()[0];

It's preferred to use `Services.locale` for this API and you have `getAppLocaleAsBCP47` method on it so that you don't need to ask for the whole list and then pick only the first of them :)

::: browser/locales/en-US/browser/preferences/preferences.ftl
@@ +212,5 @@
>  
> +# Variables:
> +#    $localeName {string} - Localized name of the locale to be used.
> +use-system-locale =
> +    .label = Use System Locale ({ $localeName }) for Regional Preferences.

We're trying to unify the l10n ids in this file using a shared prefix for all strings in a section. Could you do `locale-use-system` (and we'll start using `locale-` for all strings related to language selection)?
Attachment #8962485 - Flags: review?(jaws)
Attachment #8962485 - Flags: review?(gandalf)
Attachment #8962485 - Flags: feedback+
that looks good to me (with a couple comments). I'm redirecting r? to Jared since I'm not in a position to decide on UX changes to Preferences.
Assignee: nobody → zach.x.nickell
Status: NEW → ASSIGNED
Comment on attachment 8962485 [details] [diff] [review]
Add preferences option for use system locale v2

Review of attachment 8962485 [details] [diff] [review]:
-----------------------------------------------------------------

Holding back r+ until we get sign-off on the wording here. The location in preferences is correct.

::: browser/app/profile/firefox.js
@@ +1207,4 @@
>  pref("services.sync.prefs.sync.extensions.personas.current", true);
>  pref("services.sync.prefs.sync.extensions.update.enabled", true);
>  pref("services.sync.prefs.sync.intl.accept_languages", true);
> +pref("services.sync.prefs.sync.intl.regional_prefs.use_os_locales", true);

I don't know if this pref should be synced, since it should only be used on machines where the system locale and the install locale are different. This may be true on one machine but not on another, though I guess if they are the same then this won't have a noticeable difference.

::: browser/components/preferences/in-content/main.js
@@ +859,5 @@
>      gSubDialog.open("chrome://browser/content/preferences/languages.xul");
>    },
>  
> +  displayUseSystemLocale() {
> +    var appLocale =

Please use `let` instead of `var` here and below.

@@ +873,5 @@
> +    // We will want to do a better comparison of the locale tags here after Bug 1349377 is completed.
> +    if (appLocale.split("-u-")[0] != systemLocale.split("-u-")[0]) {
> +      ChromeUtils.import("resource://gre/modules/InlineSpellChecker.jsm");
> +      var isc = new InlineSpellChecker;
> +      var systemLocaleName = isc.getDictionaryDisplayName(systemLocale);

rename `systemLocaleName` to `localeName`.

@@ +875,5 @@
> +      ChromeUtils.import("resource://gre/modules/InlineSpellChecker.jsm");
> +      var isc = new InlineSpellChecker;
> +      var systemLocaleName = isc.getDictionaryDisplayName(systemLocale);
> +      var checkbox = document.getElementById("useSystemLocale");
> +      document.l10n.setAttributes(checkbox, "use-system-locale", {localeName: systemLocaleName});

document.l10n.setAttributes(checkbox, "use-system-locale", {localeName});

::: browser/components/preferences/in-content/main.xul
@@ +308,5 @@
>    </hbox>
>  
> +  <checkbox id="useSystemLocale" hidden="true"
> +          data-l10n-id="use-system-locale"
> +          preference="intl.regional_prefs.use_os_locales"/>

Please align these two lines with the start of the first attribute on line 310.

::: browser/locales/en-US/browser/preferences/preferences.ftl
@@ +212,5 @@
>  
> +# Variables:
> +#    $localeName {string} - Localized name of the locale to be used.
> +use-system-locale =
> +    .label = Use System Locale ({ $localeName }) for Regional Preferences.

Let's ask Meridel about the wording here.
Attachment #8962485 - Flags: review?(jaws) → feedback+
@Meridel, the string proposed here is "Use System Locale ({ $localeName }) for Regional Preferences." and this would be used when Firefox is installed with a different locale than the operating system it is installed on. Personally I think this text may be too jargony, and we might not have the right casing either. Does this look OK to you?
Flags: needinfo?(philipp) → needinfo?(mwalkington)
Hi Jared:

A couple of questions, please:
-Where do dates appear? Can you point me to an example? This will inform the copy.
-Do we have a visual mock-up for how this will appear in Prefs?
-Do we need to take into account both short and long forms of dates? Ex: January 12, 2018 and 1/12/2018. 

As for copy, I agree that it is too jargony and it should be in sentence case, not title case. I'd like to avoid saying "System Locale" and "Regional Preferences." Here are two options. Let me know what you think:

Option 1, checkbox: 
Firefox displays dates as month/day/year.
[X] Display dates as day/month/year, instead.

If we need to account for short and long date types:
[Radio]:
Choose how dates are formatted:
Short dates: [Options in drop down]
Long dates: [Options in drop down]
Flags: needinfo?(mwalkington) → needinfo?(jaws)
Hi Meridel, I think I can answer your question. Let me try :)

The preferences is not about just selecting the date format. There is a large body of preferences that are considered regional specific. Those items are things like date format, time format, calendar format, hour cycle (is your clock 24h or 12h?), does the week start on Monday, Sunday or some other day. It's also about what units you use (imperial vs metric), what temperature units (celsius, farenheit etc.) and so on. There's a lot.

When the user installs Firefox, they do so in a specific locale - for example a user may install Firefox es-CL which means they install Chilean Spanish Firefox.

That, in turn, means that they are going to receive a Spanish translation and Chilean regional preferences by default.

Unfortunately, the picture gets more complicated, because users sometimes want to install Firefox in one locale (often en-US), but their preferred regional preferences are different. Since Firefox does not provide its own regional preferences settings, while all modern operating systems do, we can just look into those operating system settings and learn what preferences user has there.

There are more details in exactly how this happens, but the bottom line is that we in some cases can do this automatically, and in others we will not do this unless the user explicitly requested.

That's what the pref is for.

So, the pref is communicating something like "Please, force Firefox to always use my operating system's regional preferences (es-CL) when formatting regional preferences in Firefox, rather than using the regional preferences based on my Firefox's locale".

The trick is how to make it look easy for the user to understand :)

My concern with your proposal is that it communicates to the user that the selection is only going to affect dates, while in fact the range of items, and the term used by Windows, MacOS and Android is "Regional Preferences" (name of the UI in Options/Preferences in all of the OSes)

Two things that help:

1) We would show this UI only in case the user's Firefox locale and Windows locale differ, so majority of users will not be exposed to it
2) For the users who are exposed to it, they are likely more familiar with the concepts around locale selection since they manually select their loclaes at least in one case (in other words, they had to select their locale in Windows, and now downloaded Firefox in a different locale, at least one of those two likely happened due to their manual, conscious choice).

In result, I would hope that some option like:

```
Use Operating System's Regional Preferences (es-CL) in Firefox (en-US) [x]
```

or:

```
Override Firefox's locale (en-US) with Operating System's one (es-CL) when formatting regional preferences [x]
```


or something in that line, would be likely understood by the population affected by the choice. We can show the locale code or locale name ("Spanish (Chile)" and "English (United States)"), but that's going to make it longer.

Do you think that we should stick to communicating about dates?
Flags: needinfo?(jaws) → needinfo?(mwalkington)
I'd go for:
  Use "Spanish (Chile)" from Regional Settings when formatting dates and times [x].
or
  Use Regional Settings (Spanish (Chile)) when formatting dates and times [x].

You can find dates and times in bookmarks (date added/visited), the browsing history, page info and details of certificates. Of course Zibi is right and there are other places where this will have an effect, but date/time display is the most prominent one.
Thanks Zibi and Jorg. The context is super helpful! 

-Zibi, all of the examples you mentioned were either date, time, or unit of measurement. If those three cover the entire range of where this would show up, then I'd like to use those in the language if we have the room. 

-Is it absolutely necessary that we say "Regional Settings"? I'm wondering if we save room, and communicate the point clearly enough, with just this:

[X] Use ({ $localeName }) when formatting dates, times, and units of measurement. 

If you think it is critical for understanding to include "Regional Settings", then you could do this:

[X] Use Regional Settings, ({ $localeName }), for formatting dates, times, and units of measurement.


Too long? If so, you could do this (I prefer not to use 'et cetera', though):

[X] Use Regional Settings, ({ $localeName }), for formatting dates, times, et cetera.
Flags: needinfo?(mwalkington) → needinfo?(gandalf)
(In reply to Meridel from comment #22)
> -Zibi, all of the examples you mentioned were either date, time, or unit of
> measurement. If those three cover the entire range of where this would show
> up, then I'd like to use those in the language if we have the room. 

You can see a sample of how the UI for regional preferences looks like in different Operating Systems by looking at the attached screenshots in bug 1308329

From the list I see:
 - date/time format patterns
 - number format patterns
 - unit formats
 - list formats
 - calendar selection

> -Is it absolutely necessary that we say "Regional Settings"? I'm wondering
> if we save room, and communicate the point clearly enough, with just this:
> 
> [X] Use ({ $localeName }) when formatting dates, times, and units of
> measurement. 
>
> If you think it is critical for understanding to include "Regional
> Settings", then you could do this:
> 
> [X] Use Regional Settings, ({ $localeName }), for formatting dates, times,
> and units of measurement.
> 
> Too long? If so, you could do this (I prefer not to use 'et cetera', though):
> 
> [X] Use Regional Settings, ({ $localeName }), for formatting dates, times,
> et cetera.


I'm not sure if it is necessary. I know that this is the name operating systems use (both MacOS and Windows), which may make it familiar for the user searching for some settings related to it.

In case of the example you gave above - that would indicate that the user is hard-setting the locale which is currently the OS regional preferences locale, rather than setting Firefox to follow the OS locale. The difference is that if the user will later change the locale in their OS, Firefox will follow.

It's a bit hard to estimate how impactful it is. On one hand, we are talking about the UX for edge case users. On the other, for those that are affected it is pretty important that they fine tune it to their expectations.

I don't have UX expertise necessary to asses the balance between correctness, familiarity and simplicity. I'd only point out that this checkbox is not meant to be "discovered" by the user like most of Preferences are. We do not expect user to learn about it as they go through Preferences and customize Firefox.

This is more of a "safety valve" meant for users who expect Firefox to follow the OS regional preferences locales, see the wrong date, time or number format, and look for a way to switch it to their liking.

For that reason I expect such a user to search Preferences for terms like "Operating System, Regional Preferences, locales, languages, format".

I'd leave the decision to you, just providing input from the l10n perspective.
Flags: needinfo?(gandalf) → needinfo?(mwalkington)
Since the user is changing a preference while in Firefox, it's not necessary to say that they are changing it in Firefox. Zibi and I talked on Slack and here is the copy: 

[X] Use Operating System's locale, ({ $localeName }), for formatting dates, times, numbers, et cetera. 

Michelle, can you please provide sign-off as Prefs content owner?
Flags: needinfo?(mwalkington) → needinfo?(mheubusch)
Two things: I think the most prominent places which are affected are date and time formatting. Sure, there are measurements as well, but where do they show, Zibi? Are the KB or MB formatted according to the region? You might consider dropping the "et cetera" since the user will wonder what that entails.

As for the proposal:
[X] Use Operating System's locale, ({ $localeName }), for formatting dates, times, numbers, et cetera.

Sadly there are two locales in the operating system, at least on Windows. There is the system locale which for example controls in which encoding Windows file names are returned. This encoding differs for example between European users who might have äöüáîß in their file names and Japanese users. That is really an administrative setting that users should play around with. It also requires a restart!

The locale that controls the formatting of date, time and units is in the regional settings.

So "Operating System's locale" is ambiguous. Hence the proposal to use "Regional Settings".

While I was afk I though about this proposal:
[X] Use "Spanish (Chile)" instead of "English (United States)" for formatting dates, times, numbers, et cetera.

I think "" are better than () and the user will notice that they configured "Spanish (Chile)" somewhere in the OS, or they live there and it's just natural, and that "English (United States)" relates to the software that they are using.

Anyway, just my 2 cents worth of wisdom.
Jorg, I like your recommendation. It's clear and does not use any jargon. The "et cetera" is still a bit mysterious. If we had the room, this would cover all the use cases I believe?:

[X] Use "Spanish (Chile)" instead of "English (United States)" for formatting dates, times, numbers, and units of measurement.

Zibi, thoughts?
Flags: needinfo?(gandalf)
My concern about this wording is that it indicates a permanent change to a selected locale. The wording (to me) very strongly says "Set Spanish as my language to format dates".

In fact, we are not setting any particular locale, we just switch the locale selection mechanism to follow the OS one. In this message there is no information about:

1) Why Spanish Chilean? Where did we pick it from?
2) If the user will switch their OS regional preferences locale from Spanish Chilean to Russian, Firefox with this checkbox enabled will switch to Russian as well.

I'm not sure how important it is because as I said I feel like this UX is on one hand edge case, and on the other people who are affected are likely very familiar with the UX around it (since they care and spent time fine tuning their settings in the OS).

If you think it's the right choice, I'm totally ok with it. We can always revisit it if we encounter reports from confused users due to (1) or (2).
Flags: needinfo?(gandalf)
Thanks, Zibi. It sounds like the string, "[X] Use "Spanish (Chile)" instead of "English (United States)" for formatting dates, times, numbers, and units of measurement" is not accurate. Taking Jorg's feedback about the elements impacted by this and the use of commas vs. parentheses, as well as your approval of my earlier string, I recommend the following:

[X] Use Operating System's locale, "{ $localeName }", for formatting dates, times, numbers, and units of measurement.

How does that look? I'll run this by Michelle, as well.
Flags: needinfo?(gandalf)
that looks good to me!
Flags: needinfo?(gandalf)
Attached image region.png — 
Sorry to be annoying, but let me repeat from comment #25:
"Operating System's locale" is not precise and in fact misleading.

Please take a look at the screenshot. The word "locale" is associated with the "system locale" and changing that has no effect on the formatting. Besides, no layman knows what a locale is.

So you should really use:
[X] Use Operating System's _________, "{ $localeName }", for formatting dates, times, numbers, and units of measurement.
And in the blank space you can fill one of
  settings
  regional settings
  format.

Or how about:
[X] Apply Operating System's format for "{ $localeName }" to dates, times, numbers, and units of measurement.

That must be the winner since it's short and everyone understands "format" ;-)
Haha, Jorg is right. This is madness!

> [X] Apply Operating System's format for "{ $localeName }" to dates, times, numbers, and units of measurement.

This is also an approximation because:

1) It's not a single format that will be applied. It's a set of preferences
2) We're not applying anything. We're asking Firefox to use OS regional preferences locales...

Ugh, I start to think that we won't be able to find a perfect phrase that would both be accurate and user friendly.

> Besides, no layman knows what a locale is.

I'd argue that no layman sets OS regional preferences locale, download Firefox in a different locale and looks for a setting to make Firefox use the OS ones.
This is an edge case for multilingual users who are already familiar enough with the domain to look through MacOS or Windows settings, find the regional preferences settings, customize them and use OS and a browser in two different locales.

Let me try:

```
[X] Use Operating System's settings when formatting dates, times, numbers and units of measurement.
```

We don't really need to tell the user what locale it'll be, since this option will be showed only when Windows and Firefox language is different.

If we wanted to be very explicit and take more space we could do what Windows is doing and show examples:

```
[X] Use Operating System's settings when formatting dates, times, numbers and units of measurement.

Examples:
Date: 12/25/2018
Time: 23:34
```

and if the user unchecks it it would show:

```
[ ] Use Operating System's settings when formatting dates, times, numbers and units of measurement.

Examples:
Date: 25/12/2018
Time: 11:34 pm
```

but I'm really not sure if we should take that much space for such an esoteric feature, even if the whole thing will be displayed only to users who might be interested.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #31)
> ```
> [X] Use Operating System's settings when formatting dates, times, numbers
> and units of measurement.
> ```
That's a variation on what I had in comment #30 using "settings".
[X] Use Operating System's settings, "{ $localeName }", for formatting dates, times, numbers, and units of measurement.

I think showing the locale so the user doesn't have to dig it out from the control panel would help:
[X] Use Operating System's settings for "{ $localeName }" when formatting dates, times, numbers, and units of measurement.

For example:
[X] Use Operating System's settings for "German (Germany)" when formatting dates, times, numbers, and units of measurement.

BTW Zibi, you mixed up your example formats: 12/25/2018 and 23:34 don't go together, and 25/12/2018 and 11:34 pm either. Madness!
> I think showing the locale so the user doesn't have to dig it out from the control panel would help:

Showing the locale, for me, indicates that this checkbox changes to that locale, rather than changing the strategy to follow the locale selection. That's the inaccurate part in my previous description.

I understand the point about digging, but notice that in order to have any setting there the user had to consciously get to that UI and change it, so it's not like they won't know.
I have never encountered a user who is:

a) picky enough to reach out to us to demand this feature
b) doesn't know what language they selected

We're talking about population that is very, very aware of what they are doing and this meticulous approach to selection of languages, regions and customization of formats makes them request that Firefox follows that selection.

You're describing a persona that is an average user that somehow wants this feature set. I think it's misleading.

Bottom line - I think it's bikeshedding at this point. As I said, I doubt we can get both - accurate and user friendly language for this message. I'd like to leave it up to UX to decide which one we'll give up on.
OK, so proposal Zibi:
[X] Use Operating System's settings when formatting dates, times, numbers and units of measurement.

Proposal Jörg:
[X] Use Operating System's settings for "{ $localeName }" when formatting dates, times, numbers, and units of measurement.
Example:
[X] Use Operating System's settings for "German (Germany)" when formatting dates, times, numbers, and units of measurement.

Both fine, they only differ in `for "{ $localeName }"`.

> You're describing a persona that is an average user that somehow wants this feature set. I think it's misleading.
There has been a long discussion about date/time formatting. Some people said that "most" programs follow the system settings, so why not Firefox. So when the average user goes looking for settings, it would be good to show them their locale so with a sigh of relief they can say: Yes, this one!

I know many people who use English versions of software since a localised one is not available or of bad quality, or since they are part of the open source world and need to work in English, yet want their own localised formats.

Bikeshedding, so I'll stop. IMHO, we have two viable options.
Thanks both for this illuminating discussion! I will ask Michelle to make final call as she leads content for UX. Last questions and suggestion from me before I do that:

-Zibi: "Showing the locale, for me, indicates that this checkbox changes to that locale, rather than changing the strategy to follow the locale selection. " Can you explain what you mean by this? I think showing the locale just helps clarify things for the user. I know the target users may not need this sort of help but if we do get users who have questions, why not make it clear?
-Am I correct in understanding that we are giving the user the ability to change how Firefox renders dates/times/etc. according to the language of their operating system? If so, could we use "language" instead of either "settings" or "locale"? I see in the screenshot Jorg provided that they use the string "Language for non-Unicode programs"...
-"use the operating system's settings for German (Germany)" could imply that there are multiple settings for German/Germany, which doesn't seem right. If there is really just one way of formatting dates/times/etc. according to location/language, then I think this string would be better:

[X] Use Operating System's language ("German (Germany)") to format dates, times, numbers, and units of measurement.
Flags: needinfo?(gandalf)
(In reply to Meridel from comment #35)
> [X] Use Operating System's language ("German (Germany)") to format dates,
> times, numbers, and units of measurement.
Surely you don't want parenthesis and double-quotes, right? Since in most cases you will already have parenthesis around the country, I suggest to go with quotes only.

In most cases it will be the language of the operating system, but you can chose another language/settings/locale for the formatting. Like I have and English (US) OS, and I might choose "German (Germany)" for the formatting.
Yes, good catch. I prefer parentheses to decrease emphasis since most users will already know what they have but I also don't like then having the double parentheses so let's go with quotations:

[X] Use Operating System's language, "German (Germany), to format dates, times, numbers, and units of measurement.

Re: In most cases it will be the language of the operating system, but you can chose another language/settings/locale for the formatting. Like I have and English (US) OS, and I might choose "German (Germany)" for the formatting.

I understand you can select another language/settings/locale for formatting, but for this particular string, aren't we just asking about whether they want to use operating system language?
Flags: needinfo?(jorgk)
(In reply to Meridel from comment #37)
> I understand you can select another language/settings/locale for formatting,
> but for this particular string, aren't we just asking about whether they
> want to use operating system language?
No.

In the attached screen shot, I combined two panels:
Region, Format (tab), Format (heading) and
Region, Administrative.

Forget the latter, this is about the *system* locale, see comment #25. Sadly Windows refers to is as "language". Changing the system locale has no effect.

So with the check-mark we're asking Firefox to use the "language" under "Region, Format, Format" which does not have to be the language of the UI of the OS. With Windows 10 you can install a certain language of the OS, and then each user can still choose their own language for the UI. But the language of the UI is *not* necessarily the language used for formatting.

So the correct sentence would be as suggested in comment #30:
[X] Use Operating System's _________, "German (Germany)", to format dates, times, numbers, and units of measurement.
And in the blank space you can fill one of
  settings
  regional settings
  formats.

I don't really like that you have commas around the language/country, I think the suggestion in comment #34 is still best:
[X] Use Operating System's settings for "German (Germany)" when formatting dates, times, numbers, and units of measurement.

Better would to use "formats", but then you repeating the word:
[X] Use Operating System's formats for "German (Germany)" when formatting dates, times, numbers, and units of measurement.

OK, how about:
[X] Use Operating System's formats for "German (Germany)" for dates, times, numbers, and units of measurement.
Flags: needinfo?(jorgk)
Got it, thanks for explaining.

"Formats" is a bit clunky. We landed on "Settings" in Comment 34 and I agree with using that. Recommending this:

[X] Use Operating System's settings for "German (Germany)" to format dates, times, numbers, and units of measurement.
Flags: needinfo?(jorgk)
Fine by me :-) - No further questions here, so clearing NI.
Flags: needinfo?(jorgk)
Great! Michelle, I think we landed on a string for this. Need-Info-ing you as official approver of Preferences content:

[X] Use Operating System's settings for "German (Germany)" to format dates, times, numbers, and units of measurement.
Hahaha, it always amazes me how deep the rabbit hole can be! :)

> -Zibi: "Showing the locale, for me, indicates that this checkbox changes to that locale, rather than changing the strategy to follow the locale selection. " Can you explain what you mean by this? I think showing the locale just helps clarify things for the user. 

Let's imagine the following pattern of steps:

1) User selects German in their Operating System as their Regional Preferences Locale.
2) User downloads Firefox in English
3) User opens the Preferences in Firefox and see the following checkbox:
```
[ ] Use Operating System's settings for "German (Germany)" to format dates, times, numbers, and units of measurement.
```
4) User checks the checkbox and as expected dates, times, numbers and units are displayed in German using German formats. Alles gut.
5) User goes to Operating System Regional Preferences UI and changes their language there to Spanish.

What should happen in Firefox?

Based on the language of the message, I'd expect Firefox to continue formatting dates/times etc. to German, because that's what the user selected.

But the algorithm we have will make us now use Spanish, because the checkbox in reality just makes us follow whatever the OS locale for regional preferences is.

That's what I think is mildly confusing, but please, notice that I believe it to be an edge case, of an edge case, affecting very very few very peculiar users with very strong preferences who are perfectly capable of figuring that out :)
In result, I'm ok with any approximation of the message ;)

I'm perfectly ok with the message proposed in comment 41. I wish there was a shorter way to say that, and I hope that one day we'll accumulate enough of settings like this to have a separate Preferences panel with examples, but that's pretty far out :)
Flags: needinfo?(gandalf)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #42)
> But the algorithm we have will make us now use Spanish, because the checkbox
> in reality just makes us follow whatever the OS locale for regional
> preferences is.
When you revisit the preferences, you will now see:
[ ] Use Operating System's settings for "Spanish (Spain)" to format dates, times, numbers, and units of measurement.
Meridel - any progress on getting an UX consensus here?
Flags: needinfo?(mwalkington)
Apologies - I have time with Michelle on Thursday and will run the final string by her then.

It sounds like, based on your and Jorg's last comment, that this string still works best for us:

[X] Use Operating System's settings for "German (Germany)" to format dates, times, numbers, and units of measurement.

To shorten, we could lose "units of":

[X] Use Operating System's settings for "German (Germany)" to format dates, times, numbers, and measurement.
This looks good to me.

Zach - I think you can proceed with updating the patch to Comment 45, while the UX does the final review.
Flags: needinfo?(zach.x.nickell)
(In reply to Meridel from comment #45)
> [X] Use Operating System's settings for "German (Germany)" to format dates,
> times, numbers, and measurement.
Measurements? Plural?
Here is the final - small tweaks:

[X] Use your operating system settings for "German (Germany)" to format dates, times, numbers, and measurements.
Flags: needinfo?(mwalkington)
Zibi, do you thing this should be implemented one day? Meanwhile you've done bug 1479377 and bug 1469688, but this one is still open.
Flags: needinfo?(gandalf)

Wow, after dozens of comments of discussion, this was abandoned :-(

Flags: needinfo?(gandalf)

Hello, Can I work on this?
I have gone through the comments, and I think what should be written beside the checkbox has been discussed in the last few comments.
Thanks :)
Aarushi

Flags: needinfo?(gandalf)

Sure! Let me know if you need help!

Flags: needinfo?(gandalf)

Sure. The patch might still apply, .xul is now .xhtml, and the wording for the message is in comment #45.

Assignee: zach.x.nickell → aarushivij
Flags: needinfo?(zach.x.nickell)
Flags: needinfo?(mheubusch)

Thank you for the patch! I redirected the r? to jaws since it's part of Preferences UI, and should be approved by front-end and UX. For me the patch looks good!

I'm not sure if we should sync it across sync - this seems like a per-system override.

Attachment #9138307 - Attachment description: Bug 1379910 - Add Preference option to change the locale strategy for regional preferences r=zbraniecki → Bug 1379910 - Add Preference option to change the locale strategy for regional preferences

Hey @jaws I have updated the patch.
Please review :)
Shall make changes if any
Thanks
Aarushi

Flags: needinfo?(jaws)
Attachment #9138307 - Attachment description: Bug 1379910 - Add Preference option to change the locale strategy for regional preferences → Bug 1379910 - Add Preference option to change the locale strategy for regional preferences r=zbraniecki
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/77d86775b008
Add Preference option to change the locale strategy for regional preferences r=fluent-reviewers,jaws,flod
Backout by dvarga@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/40fdd9eb9f97
Backed out changeset 77d86775b008 for causing multiple brwoser-chrome failures

Hello, @jaws and @gandalf , please help with the error.
All are related to localeName , But I cannot resolve what is wrong.

Flags: needinfo?(aarushivij) → needinfo?(gandalf)
Flags: needinfo?(jaws)
Flags: needinfo?(gandalf)
Pushed by jwein@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d7e299be215a
Add Preference option to change the locale strategy for regional preferences r=fluent-reviewers,jaws,flod

Backed out changeset d7e299be215a (bug 1379910) for failures on browser_ElapsedTime.js

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&fromchange=45b51bfd292544dae524521bc310a5514e07f52a&searchStr=linux%2C18.04%2Cx64%2Cdebug%2Cmochitests%2Cwith%2Cfission%2Cenabled%2Ctest-linux1804-64%2Fdebug-mochitest-browser-chrome-fis-e10s-11%2Cm-fis%28bc11%29&tochange=c21c8e61904732175775b6ecac7fb86b66dff2ad&selectedJob=298687191

Backout link: https://hg.mozilla.org/integration/autoland/rev/c21c8e61904732175775b6ecac7fb86b66dff2ad

Failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=298687191&repo=autoland&lineNumber=23797

[task 2020-04-21T20:08:14.256Z] 20:08:14     INFO - TEST-START | dom/ipc/tests/browser_ElapsedTime.js
[task 2020-04-21T20:08:14.258Z] 20:08:14     INFO - GECKO(12257) | Chrome file doesn't exist: /builds/worker/workspace/build/tests/mochitest/browser/dom/ipc/tests/head.js
[task 2020-04-21T20:08:14.373Z] 20:08:14     INFO - GECKO(12257) | ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /tmp/tmp7mfaqn.mozrunner/runtests_leaks_tab_pid12541.log
[task 2020-04-21T20:08:14.374Z] 20:08:14     INFO - GECKO(12257) | [12541, Main Thread] WARNING: XPCOM_MEM_BLOAT_LOG is set, disabling native allocations.: file /builds/worker/checkouts/gecko/tools/profiler/core/platform.cpp, line 221
[task 2020-04-21T20:08:14.803Z] 20:08:14     INFO - GECKO(12257) | [Child 12541, Main Thread] WARNING: could not set real-time limit at process startup: file /builds/worker/checkouts/gecko/dom/ipc/ContentChild.cpp, line 1675
[task 2020-04-21T20:08:14.811Z] 20:08:14     INFO - GECKO(12257) | [Child 12541: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 0x7f20813d7c00 == 1 [pid = 12541] [id = {0d0e506b-97a6-42b3-970b-3380f8268da8}]
[task 2020-04-21T20:08:14.831Z] 20:08:14     INFO - GECKO(12257) | [Child 12541: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 1 (0x7f2096993350) [pid = 12541] [serial = 1] [outer = (nil)]
[task 2020-04-21T20:08:14.831Z] 20:08:14     INFO - GECKO(12257) | [Child 12541: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 2 (0x7f207bd81400) [pid = 12541] [serial = 2] [outer = 0x7f2096993350]
[task 2020-04-21T20:08:14.932Z] 20:08:14     INFO - GECKO(12257) | [Child 12541: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 3 (0x7f207bddd000) [pid = 12541] [serial = 3] [outer = 0x7f2096993350]
[task 2020-04-21T20:08:15.151Z] 20:08:15     INFO - GECKO(12257) | [Child 12541, Main Thread] WARNING: NS_ENSURE_TRUE(request) failed: file /builds/worker/checkouts/gecko/netwerk/base/nsLoadGroup.cpp, line 591
[task 2020-04-21T20:08:15.200Z] 20:08:15     INFO - GECKO(12257) | ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /tmp/tmp7mfaqn.mozrunner/runtests_leaks_tab_pid12569.log
[task 2020-04-21T20:08:15.200Z] 20:08:15     INFO - GECKO(12257) | [12569, Main Thread] WARNING: XPCOM_MEM_BLOAT_LOG is set, disabling native allocations.: file /builds/worker/checkouts/gecko/tools/profiler/core/platform.cpp, line 221
[task 2020-04-21T20:08:15.605Z] 20:08:15     INFO - GECKO(12257) | [Child 12569, Main Thread] WARNING: could not set real-time limit at process startup: file /builds/worker/checkouts/gecko/dom/ipc/ContentChild.cpp, line 1675
[task 2020-04-21T20:08:15.613Z] 20:08:15     INFO - GECKO(12257) | [Child 12569: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 0x7f88ce7dc400 == 1 [pid = 12569] [id = {0d0e506b-97a6-42b3-970b-3380f8268da8}]
[task 2020-04-21T20:08:15.629Z] 20:08:15     INFO - GECKO(12257) | [Child 12569: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 1 (0x7f88e3d93350) [pid = 12569] [serial = 1] [outer = (nil)]
[task 2020-04-21T20:08:15.631Z] 20:08:15     INFO - GECKO(12257) | [Child 12569: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 2 (0x7f88c91b7c00) [pid = 12569] [serial = 2] [outer = 0x7f88e3d93350]
[task 2020-04-21T20:08:15.814Z] 20:08:15     INFO - GECKO(12257) | [Child 12569: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 3 (0x7f88c91c3400) [pid = 12569] [serial = 3] [outer = 0x7f88e3d93350]
[task 2020-04-21T20:08:15.880Z] 20:08:15     INFO - GECKO(12257) | [Parent 12257, Main Thread] WARNING: '!mName', file /builds/worker/checkouts/gecko/editor/libeditor/EditAggregateTransaction.cpp, line 92
[task 2020-04-21T20:08:15.880Z] 20:08:15     INFO - GECKO(12257) | [Parent 12257, Main Thread] WARNING: EditAggregationTransaction::GetName() failed: 'NS_SUCCEEDED(rv)', file /builds/worker/checkouts/gecko/editor/libeditor/PlaceholderTransaction.cpp, line 217
[task 2020-04-21T20:08:15.880Z] 20:08:15     INFO - GECKO(12257) | [Parent 12257, Main Thread] WARNING: nsIAbsorbingTransaction::GetTxnName() failed, but ignored: 'NS_SUCCEEDED(rvIgnored)', file /builds/worker/checkouts/gecko/editor/libeditor/PlaceholderTransaction.cpp, line 188
[task 2020-04-21T20:08:15.955Z] 20:08:15     INFO - GECKO(12257) | [Parent 12257, Main Thread] WARNING: '!mName', file /builds/worker/checkouts/gecko/editor/libeditor/EditAggregateTransaction.cpp, line 92
[task 2020-04-21T20:08:15.955Z] 20:08:15     INFO - GECKO(12257) | [Parent 12257, Main Thread] WARNING: EditAggregationTransaction::GetName() failed: 'NS_SUCCEEDED(rv)', file /builds/worker/checkouts/gecko/editor/libeditor/PlaceholderTransaction.cpp, line 217
[task 2020-04-21T20:08:15.955Z] 20:08:15     INFO - GECKO(12257) | [Parent 12257, Main Thread] WARNING: nsIAbsorbingTransaction::GetTxnName() failed, but ignored: 'NS_SUCCEEDED(rvIgnored)', file /builds/worker/checkouts/gecko/editor/libeditor/PlaceholderTransaction.cpp, line 188
[task 2020-04-21T20:08:16.096Z] 20:08:16     INFO - GECKO(12257) | ### XPCOM_MEM_BLOAT_LOG defined -- logging bloat/leaks to /tmp/tmp7mfaqn.mozrunner/runtests_leaks_tab_pid12597.log
[task 2020-04-21T20:08:16.098Z] 20:08:16     INFO - GECKO(12257) | [12597, Main Thread] WARNING: XPCOM_MEM_BLOAT_LOG is set, disabling native allocations.: file /builds/worker/checkouts/gecko/tools/profiler/core/platform.cpp, line 221
[task 2020-04-21T20:08:16.435Z] 20:08:16     INFO - GECKO(12257) | [Child 12597, Main Thread] WARNING: could not set real-time limit at process startup: file /builds/worker/checkouts/gecko/dom/ipc/ContentChild.cpp, line 1675
[task 2020-04-21T20:08:17.701Z] 20:08:17     INFO - GECKO(12257) | [Child 12336: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 3 (0x7f2a4b98b400) [pid = 12336] [serial = 2] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:17.724Z] 20:08:17     INFO - GECKO(12257) | [Child 12336: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 2 (0x7f2a66593350) [pid = 12336] [serial = 1] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:18.362Z] 20:08:18     INFO - GECKO(12257) | [Child 12312: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 14 (0x7ff7c0350c00) [pid = 12312] [serial = 10] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:18.363Z] 20:08:18     INFO - GECKO(12257) | [Child 12312: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 13 (0x7ff7c034c800) [pid = 12312] [serial = 6] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:18.364Z] 20:08:18     INFO - GECKO(12257) | [Child 12312: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 12 (0x7ff7c034ac00) [pid = 12312] [serial = 4] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:18.364Z] 20:08:18     INFO - GECKO(12257) | [Child 12312: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 11 (0x7ff7ba42c000) [pid = 12312] [serial = 2] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:18.365Z] 20:08:18     INFO - GECKO(12257) | [Child 12312: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 10 (0x7ff7c034e800) [pid = 12312] [serial = 8] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:18.432Z] 20:08:18     INFO - GECKO(12257) | [Child 12312: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 9 (0x7ff7d5993520) [pid = 12312] [serial = 3] [outer = (nil)] [url = moz-extension://78d413a8-8b81-44e2-881e-c044f841a901/_generated_background_page.html]
[task 2020-04-21T20:08:18.433Z] 20:08:18     INFO - GECKO(12257) | [Child 12312: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 0x7ff7ba42d400 == 4 [pid = 12312] [id = {bc5ae19d-9351-40c1-8be6-55a50ac0aea4}] [url = moz-extension://78d413a8-8b81-44e2-881e-c044f841a901/_generated_background_page.html]
[task 2020-04-21T20:08:20.603Z] 20:08:20     INFO - GECKO(12257) | [Parent 12257: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 13 (0x7f3924926000) [pid = 12257] [serial = 13] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:20.603Z] 20:08:20     INFO - GECKO(12257) | [Parent 12257: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 12 (0x7f39258d2800) [pid = 12257] [serial = 8] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:20.820Z] 20:08:20     INFO - GECKO(12257) | [Parent 12257: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 0x7f39221fe400 == 5 [pid = 12257] [id = {3b00b916-6eee-423d-b762-5277c4319f86}] [url = about:blank]
[task 2020-04-21T20:08:20.820Z] 20:08:20     INFO - GECKO(12257) | [Parent 12257: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 11 (0x7f3925e292b0) [pid = 12257] [serial = 12] [outer = (nil)] [url = about:tabcrashed?e=tabcrashed&u=about%3Ablank&c=UTF-8&d=%20]
[task 2020-04-21T20:08:21.771Z] 20:08:21     INFO - GECKO(12257) | [Child 12336: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 1 (0x7f2a4b02c400) [pid = 12336] [serial = 3] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:21.772Z] 20:08:21     INFO - GECKO(12257) | [Child 12336: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 0 (0x7f2a4b98c400) [pid = 12336] [serial = 4] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:22.330Z] 20:08:22     INFO - GECKO(12257) | [Child 12395: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 0x7f57329d0800 == 0 [pid = 12395] [id = {2b091ac0-bceb-4204-9d9b-d9b510cfc450}] [url = about:blank]
[task 2020-04-21T20:08:22.466Z] 20:08:22     INFO - GECKO(12257) | [Child 12312: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 8 (0x7ff7ba41d800) [pid = 12312] [serial = 12] [outer = (nil)] [url = moz-extension://78d413a8-8b81-44e2-881e-c044f841a901/_generated_background_page.html]
[task 2020-04-21T20:08:22.713Z] 20:08:22     INFO - GECKO(12257) | [Child 12423: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 2 (0x7f6be8088c00) [pid = 12423] [serial = 2] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:22.990Z] 20:08:22     INFO - GECKO(12257) | [Child 12541: Main Thread]: I/DocShellAndDOMWindowLeak --DOCSHELL 0x7f20813d7c00 == 0 [pid = 12541] [id = {0d0e506b-97a6-42b3-970b-3380f8268da8}] [url = about:blank]
[task 2020-04-21T20:08:23.131Z] 20:08:23     INFO - GECKO(12257) | [Parent 12257: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 10 (0x7f3924929400) [pid = 12257] [serial = 14] [outer = (nil)] [url = about:tabcrashed?e=tabcrashed&u=about%3Ablank&c=UTF-8&d=%20]
[task 2020-04-21T20:08:27.074Z] 20:08:27     INFO - GECKO(12257) | [Child 12541: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 2 (0x7f207bd81400) [pid = 12541] [serial = 2] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:27.090Z] 20:08:27     INFO - GECKO(12257) | [Child 12541: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 1 (0x7f2096993350) [pid = 12541] [serial = 1] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:29.875Z] 20:08:29     INFO - GECKO(12257) | [Child 12569: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 2 (0x7f88c91b7c00) [pid = 12569] [serial = 2] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:31.136Z] 20:08:31     INFO - GECKO(12257) | [Child 12541: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 0 (0x7f207bddd000) [pid = 12541] [serial = 3] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:32.207Z] 20:08:32     INFO - GECKO(12257) | [Child 12395: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 1 (0x7f5747f93350) [pid = 12395] [serial = 1] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:08:36.238Z] 20:08:36     INFO - GECKO(12257) | [Child 12395: Main Thread]: I/DocShellAndDOMWindowLeak --DOMWINDOW == 0 (0x7f572d379c00) [pid = 12395] [serial = 2] [outer = (nil)] [url = about:blank]
[task 2020-04-21T20:09:44.429Z] 20:09:44     INFO - TEST-INFO | started process screentopng
[task 2020-04-21T20:09:44.655Z] 20:09:44     INFO - TEST-INFO | screentopng: exit 0
[task 2020-04-21T20:09:44.655Z] 20:09:44     INFO - Buffered messages logged at 20:08:14
[task 2020-04-21T20:09:44.657Z] 20:09:44     INFO - Entering test bound testLongElapsedTime
[task 2020-04-21T20:09:44.657Z] 20:09:44     INFO - Buffered messages logged at 20:08:15
[task 2020-04-21T20:09:44.658Z] 20:09:44     INFO - Console message: [JavaScript Error: "RemoteWebProgress failed to call onStateChange: [Exception... "Component does not have requested interface [nsIWebProgressListener.onStateChange]"  nsresult: "0x80004002 (NS_NOINTERFACE)"  location: "JS frame :: resource://gre/modules/RemoteWebProgress.jsm :: _callProgressListeners :: line 75"  data: no]" {file: "resource://gre/modules/RemoteWebProgress.jsm" line: 78}]
[task 2020-04-21T20:09:44.659Z] 20:09:44     INFO - _callProgressListeners@resource://gre/modules/RemoteWebProgress.jsm:78:16
[task 2020-04-21T20:09:44.659Z] 20:09:44     INFO - onStateChange@resource://gre/modules/RemoteWebProgress.jsm:88:10
[task 2020-04-21T20:09:44.660Z] 20:09:44     INFO - 
[task 2020-04-21T20:09:44.660Z] 20:09:44     INFO - Buffered messages finished
[task 2020-04-21T20:09:44.661Z] 20:09:44     INFO - TEST-UNEXPECTED-FAIL | dom/ipc/tests/browser_ElapsedTime.js | Test timed out - 
[task 2020-04-21T20:09:44.661Z] 20:09:44     INFO - GECKO(12257) | MEMORY STAT | vsize 3023MB | residentFast 324MB | heapAllocated 99MB
[task 2020-04-21T20:09:44.662Z] 20:09:44     INFO - TEST-OK | dom/ipc/tests/browser_ElapsedTime.js | took 90194ms
[task 2020-04-21T20:09:44.663Z] 20:09:44     INFO - Not taking screenshot here: see the one that was previously logged
[task 2020-04-21T20:09:44.663Z] 20:09:44     INFO - TEST-UNEXPECTED-FAIL | dom/ipc/tests/browser_ElapsedTime.js | Found a tab after previous test timed out: https://example.com/browser/dom/ipc/tests/elapsed_time.sjs - 
[task 2020-04-21T20:09:44.664Z] 20:09:44     INFO - GECKO(12257) | [Child 12597: Main Thread]: I/DocShellAndDOMWindowLeak ++DOCSHELL 0x7fe50e0d3400 == 1 [pid = 12597] [id = {e4a270c5-d254-4f92-9c44-6c26dbc5e171}]
[task 2020-04-21T20:09:44.665Z] 20:09:44     INFO - GECKO(12257) | [Child 12597: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 1 (0x7fe523693350) [pid = 12597] [serial = 1] [outer = (nil)]
[task 2020-04-21T20:09:44.666Z] 20:09:44     INFO - GECKO(12257) | [Child 12597: Main Thread]: I/DocShellAndDOMWindowLeak ++DOMWINDOW == 2 (0x7fe508126400) [pid = 12597] [serial = 2] [outer = 0x7fe523693350]
[task 2020-04-21T20:09:44.666Z] 20:09:44     INFO - checking window state
[task 2020-04-21T20:09:44.693Z] 20:09:44     INFO - GECKO(12257) | [Parent 12257, Main Thread] WARNING: NS_ENSURE_TRUE(GetWrapper()) failed: file /builds/worker/checkouts/gecko/dom/ipc/JSWindowActor.cpp, line 90
[task 2020-04-21T20:09:44.694Z] 20:09:44     INFO - TEST-START | dom/ipc/tests/browser_cancel_content_js.js```
Flags: needinfo?(aarushivij)
Pushed by btara@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/52b81dcf7279
Add Preference option to change the locale strategy for regional preferences r=fluent-reviewers,jaws,flod CLOSED TREE

Re-landed. Sorry for the trouble.

Flags: needinfo?(aarushivij)

https://hg.mozilla.org/mozilla-central/rev/52b81dcf7279

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
status-firefox77: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 77
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: