1629630 - javascript.use_us_english_locale break XIM input method

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect, P2)

Description

[wolf+mozilla]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

1. Set javascript.use_us_english_locale to true.
2. Try to write something using ibus in xim mode.

export GTK_IM_MODULE=xim
ibus-daemon -rd --xim

Particular method in my case was ibus-anthy for Japanese.

Resetting the option in about:config restores the ability to use ibus for entering Japanese text.

Actual results:

No text visible in the select text area.

Expected results:

The input text being visible as I'm writing.

Comment 1

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

I would be curious to know if this ever worked. If you have the time/interest/ability using mozregression with a start date of 2015-12-30 would be helpful in figuring that out...

Comment 2

[wolf+mozilla]

If I understand the output of

~/.local/bin/mozregression --pref "javascript.use_us_english_locale:true" --good 2015-12-30

correctly, this

 4:23.35 INFO: Got as far as we can go bisecting nightlies...
 4:23.35 INFO: Last good revision: c690c50b2b543b420803e8192d6e08e06b20e0a3 (2015-12-30)
 4:23.35 INFO: First bad revision: 22f51211915bf7daff076180847a7140d35aa353 (2015-12-31)

means that it never worked.

Comment 3

[wolf+mozilla]

Attachment: Output of mozregression

Comment 4

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 5

[Augusto Pace]

Hi,

Unfortunately I'm not able to reproduce this issue. Anyway I'm setting component to Core: DOM: CORE & HTML for someone to take a look at this.

Meanwhile @[e-mail] could you please give us more accurate steps to reproduce this issue?

Thanks

Comment 6

[wolf+mozilla]

Hello,

probably worth repeating is that I have

export GTK_IM_MODULE=xim
export XMODIFIERS=@im=ibus
export QT_IM_MODULE=xim

in my .bashrc (so both ibus-daemon and firefox run with these
env variables).

ibus is started as

ibus-daemon -rd --xim

I'm runnin i3 window manager but I doubt that is relevant. I'm not sure
what more I can add, there is nothing really specific about my setup :/

Normally I'm running firefox in firejail, I would expect mozregress not to do
that so that should not be requirement.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

javascript.use_us_english_locale is not really a DOM thing.
The attachment has link https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=c690c50b2b543b420803e8192d6e08e06b20e0a3&tochange=22f51211915bf7daff076180847a7140d35aa353 as regression range.
That includes bug 867501. So did this ever work?

Tom probably knows better how it should behave.

Comment 8

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

It seems like it might never have worked. With the uplift team disbanded, I'm not sure who can investigate what the root problem here is. Also I am not a significantly sophisticated Linux user to really understand what's being configured here.

Adding in tor to visibility.

wolf, if you wanted to try building FF and doing some light debugging, you could try commenting out https://searchfox.org/mozilla-central/rev/158bac3df3a1890da55bdb6ffdaf9a7ffc0bfb0a/toolkit/xre/nsAppRunner.cpp#5065 and seeing if that does anything. But this is just a shot in the dark.

Comment 9

[wolf+mozilla]

Ok so both

diff --git a/toolkit/xre/nsAppRunner.cpp b/toolkit/xre/nsAppRunner.cpp
index f3529c78759f..490c9bf27f33 100644
--- a/toolkit/xre/nsAppRunner.cpp
+++ b/toolkit/xre/nsAppRunner.cpp
@@ -5077,7 +5077,7 @@ void OverrideDefaultLocaleIfNeeded() {
// to avoid interfering with non-ASCII keyboard input on some Linux
// desktops. Otherwise fall back to the "C" locale, which is available on
// all platforms.

• setlocale(LC_ALL, "C.UTF-8") || setlocale(LC_ALL, "C");

• setlocale(LC_ALL, "en_US.UTF-8") || setlocale(LC_ALL, "C");
  }
  }

and

diff --git a/toolkit/xre/nsAppRunner.cpp b/toolkit/xre/nsAppRunner.cpp
index f3529c78759f..9dccc3d43136 100644
--- a/toolkit/xre/nsAppRunner.cpp
+++ b/toolkit/xre/nsAppRunner.cpp
@@ -5077,7 +5077,7 @@ void OverrideDefaultLocaleIfNeeded() {
// to avoid interfering with non-ASCII keyboard input on some Linux
// desktops. Otherwise fall back to the "C" locale, which is available on
// all platforms.

• setlocale(LC_ALL, "C.UTF-8") || setlocale(LC_ALL, "C");

• //setlocale(LC_ALL, "C.UTF-8") || setlocale(LC_ALL, "C");
  }
  }

Do fix this bug.

Comment 10

[wolf+mozilla]

Once more with correct formatting:

diff --git a/toolkit/xre/nsAppRunner.cpp b/toolkit/xre/nsAppRunner.cpp
index f3529c78759f..9dccc3d43136 100644
--- a/toolkit/xre/nsAppRunner.cpp
+++ b/toolkit/xre/nsAppRunner.cpp
@@ -5077,7 +5077,7 @@ void OverrideDefaultLocaleIfNeeded() {
     // to avoid interfering with non-ASCII keyboard input on some Linux
     // desktops. Otherwise fall back to the "C" locale, which is available on
     // all platforms.
-    setlocale(LC_ALL, "C.UTF-8") || setlocale(LC_ALL, "C");
+    //setlocale(LC_ALL, "C.UTF-8") || setlocale(LC_ALL, "C");
   }
 }

diff --git a/toolkit/xre/nsAppRunner.cpp b/toolkit/xre/nsAppRunner.cpp
index f3529c78759f..490c9bf27f33 100644
--- a/toolkit/xre/nsAppRunner.cpp
+++ b/toolkit/xre/nsAppRunner.cpp
@@ -5077,7 +5077,7 @@ void OverrideDefaultLocaleIfNeeded() {
     // to avoid interfering with non-ASCII keyboard input on some Linux
     // desktops. Otherwise fall back to the "C" locale, which is available on
     // all platforms.
-    setlocale(LC_ALL, "C.UTF-8") || setlocale(LC_ALL, "C");
+    setlocale(LC_ALL, "en_US.UTF-8") || setlocale(LC_ALL, "C");
   }
 }

both of these do fix this bug.

Comment 11

[Jason Orendorff [:jorendorff]]

Thank you, wolf!

Toolkit folks: This is actionable—comment 10 contains the patch.

This isn't a JS bug. The pref's name is a misnomer. At one point it affected the Date.prototype.toLocaleFormat builtin JS method. Now there are better JS methods to use, implemented with ICU, which I believe ignores the C locale system. Date.prototype.toLocaleFormat in particular is completely gone.

It's unfortunate we have anything that depends on setlocale, but no program is an island...

Comment 12

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 13

[wolf+mozilla]

Is there anything I can do to help this getting fixed? It's a bit since last update here.

Comment 14

[wolf+mozilla]

Final patch I've ended up using for my local build of firefox:

diff --git a/toolkit/xre/nsAppRunner.cpp b/toolkit/xre/nsAppRunner.cpp
index 332f340179d3..871981cd2927 100644
--- a/toolkit/xre/nsAppRunner.cpp
+++ b/toolkit/xre/nsAppRunner.cpp
@@ -5687,6 +5687,7 @@ void OverrideDefaultLocaleIfNeeded() {
     // to avoid interfering with non-ASCII keyboard input on some Linux
     // desktops. Otherwise fall back to the "C" locale, which is available on
     // all platforms.
+    setlocale(LC_ALL, "en_US.UTF-8") ||
     setlocale(LC_ALL, "C.UTF-8") || setlocale(LC_ALL, "C");
   }
 }
--
2.33.1

Comment 15

[Gian-Carlo Pascutto [:gcp]]

I'm going to mark this S2 if only because there's actually a patch so we should at least look at it!

Comment 16

[Sylvestre Ledru [:Sylvestre]]

and sorry for missing your work :(

Comment 17

[Marco Castelluccio [:marco]]

Setting severity to S3 because it isn't so frequent.
Wolf, you could submit your patch to Phabricator to ask for a review.

Comment 18

[Tom Schuster (MoCo)]

OverrideDefaultLocaleIfNeeded was removed in bug 1846224.