Open Bug 1629630 Opened 5 years ago Updated 2 years ago

javascript.use_us_english_locale break XIM input method

Categories

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

75 Branch
defect

Tracking

()

UNCONFIRMED

People

(Reporter: wolf+mozilla, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

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.

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...

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.

Attached file Output of mozregression (deleted) —
Attachment #9140772 - Attachment mime type: application/octet-stream → text/plain

Resetting severity to default of --.

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 @wolf+mozilla@wolfsden.cz could you please give us more accurate steps to reproduce this issue?

Thanks

Component: Untriaged → DOM: Core & HTML
Flags: needinfo?(wolf+mozilla)
Product: Firefox → Core

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.

Flags: needinfo?(wolf+mozilla)

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.

Blocks: 867501
Component: DOM: Core & HTML → JavaScript Engine
Flags: needinfo?(tom)

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.

Flags: needinfo?(tom)

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.

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.

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...

Component: JavaScript Engine → General
Product: Core → Toolkit
Component: General → Widget: Gtk
Product: Toolkit → Core

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.)

Severity: normal → --

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

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

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

Severity: -- → S2
Priority: -- → P2

and sorry for missing your work :(

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: