javascript.use_us_english_locale break XIM input method
Categories
(Core :: Widget: Gtk, defect, P2)
Tracking
()
People
(Reporter: wolf+mozilla, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/plain
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Steps to reproduce:
- Set javascript.use_us_english_locale to true.
- 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•5 years ago
|
||
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...
Reporter | ||
Comment 2•5 years ago
|
||
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.
Reporter | ||
Comment 3•5 years ago
|
||
Reporter | ||
Updated•5 years ago
|
Comment 4•5 years ago
|
||
Resetting severity to default of --
.
Comment 5•5 years ago
|
||
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
Reporter | ||
Comment 6•5 years ago
|
||
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•5 years ago
|
||
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•5 years ago
|
||
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.
Reporter | ||
Comment 9•5 years ago
|
||
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.
Reporter | ||
Comment 10•5 years ago
|
||
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•5 years ago
|
||
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...
Updated•5 years ago
|
Comment 12•5 years ago
|
||
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.)
Reporter | ||
Comment 13•3 years ago
|
||
Is there anything I can do to help this getting fixed? It's a bit since last update here.
Reporter | ||
Comment 14•3 years ago
|
||
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•2 years ago
|
||
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•2 years ago
|
||
and sorry for missing your work :(
Description
•