1701047 - Ibus IMEs and the compose key not functional in Firefox

Status: RESOLVED INVALID

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Sandi Vujaković [:elsandosgrande]]

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

Steps to reproduce:

A couple of months ago, I was suddenly unable to input anything using an IME, any IME; even the compose key, which presumably uses Ibus as well, stopped working. The IMEs, Mozc, Chewing, and Hangul, and the compose key work in literally every application other than Firefox Nightly, including Thunderbird Daily.

Actual results:

The characters were not interpreted and the IME did not begin compositing, as if I had been typing with a plain Bosnian keyboard (or any other non-IME keyboard layout). This holds true for the compose key as well, where it is just as if I had not pressed anything at all before pressing, say, the full-stop key twice to get an ellipsis.

Expected results:

The characters should have been interpreted and the IME should have begun compositing. The same holds true for the compose key.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::DOM: UI Events & Focus Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 5/2-5/10)]

A couple of months ago,

Hmm, in the December, I touched around there 4 times.
https://hg.mozilla.org/mozilla-central/log/tip/widget/gtk/IMContextWrapper.cpp

Could you check which one (or another fix) caused the regression with "mozregression" tool?
https://mozilla.github.io/mozregression/install.html

And which distribution are you using?

Comment 3

[Sandi Vujaković [:elsandosgrande]]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(Still not recoverd perfectly) from comment #2)

A couple of months ago,

Hmm, in the December, I touched around there 4 times.
https://hg.mozilla.org/mozilla-central/log/tip/widget/gtk/IMContextWrapper.cpp

Could you check which one (or another fix) caused the regression with "mozregression" tool?
https://mozilla.github.io/mozregression/install.html

And which distribution are you using?

I've got some school assignments to take care of at the moment, but I'll try taking a look at it today. Also, I'm on Ubuntu Groovy (I'm sorry that I forgot to mention that 😅).

Comment 4

[Sandi Vujaković [:elsandosgrande]]

Attachment: Exit code 11

So…

Comment 5

[Sandi Vujaković [:elsandosgrande]]

Attachment: Output log

Comment 6

[Sandi Vujaković [:elsandosgrande]]

Attachment: Buggy GTK with X11

I probably should have mentioned this earlier, but I predominantly use the GNOME Wayland session as opposed to the GNOME X11 session. Since Firefox on X11 becomes pure white (MOZ_X11_EGL=0 doesn't work for me for whatever reason), I couldn't check if this is a Wayland-only bug (at least at this point). When running the regression tool in the X11 session, the downloaded Firefox builds didn't outright crash, but they had so many critical(?) GTK errors that I wouldn't trust the results.

Given all of this, I'm not sure if this means anything, but at least the compose key works on pre-December builds (the compose symbol doesn't appear like it did before). I say this because the IMEs don't seem to work on even known-good builds, like 2020-11-03.

Side note
The regression GUI showed a lot of Fontconfig errors and a library that failed to load in the terminal when I ran it in the X11 session (I didn't run it from the terminal in the Wayland session).

Comment 7

[Sandi Vujaković [:elsandosgrande]]

Following the above, I have opened bug 1701318 and will proceed to manually download a few builds of Firefox Nightly that fall within the time frame that I gave the tool earlier (basically, from October to February).

Comment 8

[Sandi Vujaković [:elsandosgrande]]

So… After using a pre-release version of the tool, I could finally launch Firefox in the Wayland session, but I saw that I couldn't find a build that had this issue. After that, I thought to create a fresh profile to see if it might be something to do with my profile. Everything works fine with a fresh profile, but the behavior described above returns as soon as I copy my prefs.js file to the fresh profile. I tried to search for ime in both vimdiff and Firefox after launching it with my profile, but none of the results that came up were seemingly related with IMEs (“time” and such came up). Here's the thing: I don't recall doing anything major in about:config at around the time that this all started (or doing anything at all for that matter) and the IME address bar experiment has no effect on this (not to mention that I don't even know where to begin looking for a configuration setting that could even affect something like this). I tried enabling the Proton UI in the fresh profile — nothing changed. I tried enabling WebRender in the fresh profile — nothing changed. I tried enabling Fission — nothing changed.

If this still constitutes a valid bug, then I'll submit my prefs.js if need be. I'll also try manually downloading Nightly builds and injecting my prefs.js if time allows.

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Is this still reproducible for you?

Comment 10

[Sandi Vujaković [:elsandosgrande]]

Yes. As I stated before, it seems to stem from some preference in my prefs.js, but I can't even begin to guess as to which one is the culprit. I've thought of trying to revert the modified preferences one by one, but I have yet to get enough time (and patience) to restart Firefox Nightly dozens of times. If it were possible to supply the regression tool with my prefs.js, then I'd go that route.

Comment 11

[Sandi Vujaković [:elsandosgrande]]

Attachment: prefs.js

In hopes that somebody might have a light-bulb moment, I'm sharing my prefs.js.

---

Side note: When I tried to use this file in my Firefox Nightly profile on my Windows 10 virtual machine (VMware Workstation Player), it almost completely broke Firefox for reasons which still elude me.

Comment 12

[Sandi Vujaković [:elsandosgrande]]

Since screen recording finally started working after upgrading to Hirsute, here's a recording of the issue just so there are no misunderstandings: http://mellemws.my.to/direct/Screencast_from_2021%25E5%25B9%25B405%25E6%259C%258825%25E6%2597%25A5_19%25E6%2599%258212%25E5%2588%258624%25E7%25A7%2592.webm

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 5/2-5/10)]

Sorry for the delay to reply.

Hmm, you hit the Wayland code shipping in the regression range... In the pref.js (attachment 9223402 [details]), I feel only dom.forms.autocomplete.formautofill may be affected, but according the caller, it shouldn't affect.

Could you get a log with MOZ_LOG=nsGtkIMModuleWidgets:5,sync? It'll log all text inputs, so, please do not type anything your privacy like passwords. I'd like to see the result of

1. Launching Nightly build
2. Setting Mozc activated
3. Typing a couple of characters
4. Then, quit the process from the menu (for avoiding recording Ctrl + Q)

Comment 14

[Sandi Vujaković [:elsandosgrande]]

Attachment: Terminal output — keyboard log

Here's a screen recording that accompanies the terminal output: http://mellemws.my.to/direct/Screencast_from_2021%25E5%25B9%25B405%25E6%259C%258826%25E6%2597%25A5_03%25E6%2599%258247%25E5%2588%258627%25E7%25A7%2592.webm

---

I set the compose key to be Fn+Right Ctrl, because that's the key combination that's equivalent to the menu key on my laptop. Since I can open context menus just fine with my laptop's touchpad, I chose that key to be my compose key (this was configured in GNOME Tweaks). I'm mentioning this because Compose+Dot+Dot gives me the Unicode ellipsis symbol, as opposed to me just using three individual dots as an ellipsis.

Comment 15

[Sandi Vujaković [:elsandosgrande]]

Attachment: Terminal output — keyboard log (`Test` profile)

Accompanying screen recording: http://mellemws.my.to/direct/Screencast_from_2021%25E5%25B9%25B405%25E6%259C%258826%25E6%2597%25A5_04%25E6%2599%258207%25E5%2588%258649%25E7%25A7%2592.webm

---

This one's just for good measure (and a reference of a working profile on my laptop, which may or may not be helpful in this particular case).

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 5/2-5/10)]

Thank you for the log. According to the log, we received window blur events, but won't receive window focus events. Search "OnFocusWindow" in the log, it should be there.
https://searchfox.org/mozilla-central/rev/95c41d54c3fd65d51976d5188842a69b459a7589/widget/gtk/IMContextWrapper.cpp#737

In this case, we don't handle IME signals because of no focused window/widget in our process. Therefore, you see a lot of the following message in the log: "FAILED, the caller isn't focused window, mLastFocusedWindow=0x0".

Makoto-san, do you have any ideas about this situation in the Wayland world?

Comment 17

[Sandi Vujaković [:elsandosgrande]]

Attachment: Terminal output — keyboard log; X11

A friendly reminder that this isn't limited to Wayland (the glitching in the top left corner wasn't as bad on-screen as in the recording, but a part of the text box area glitching out of existence was definitely there on screen): http://mellemws.my.to/direct/Screencast_from_2021%25E5%25B9%25B405%25E6%259C%258826%25E6%2597%25A5_08%25E6%2599%258244%25E5%2588%258627%25E7%25A7%2592.webm

Comment 18

[Sandi Vujaković [:elsandosgrande]]

Attachment: Terminal output — keyboard log; X11 (`Test` profile)

Accompanying screen recording: http://mellemws.my.to/direct/Screencast_from_2021%25E5%25B9%25B405%25E6%259C%258826%25E6%2597%25A5_08%25E6%2599%258258%25E5%2588%258606%25E7%25A7%2592.webm

Comment 19

[Makoto Kato [:m_kato]]

Sandi, could you get the log again using MOZ_LOG="nsGtkIMModuleWidgets:5,Widget:5" on reproduced environment? (Adding Widget:5)

Comment 20

[Sandi Vujaković [:elsandosgrande]]

Attachment: Terminal output — keyboard log; verbose

Accompanying screen recording: http://mellemws.my.to/direct/Screencast_from_2021%25E5%25B9%25B405%25E6%259C%258826%25E6%2597%25A5_15%25E6%2599%258252%25E5%2588%258609%25E7%25A7%2592.webm

Comment 21

[Sandi Vujaković [:elsandosgrande]]

Attachment: Terminal output — keyboard log; verbose, X11

Accompanying screen recording: http://mellemws.my.to/direct/Screencast_from_2021%25E5%25B9%25B405%25E6%259C%258826%25E6%2597%25A5_16%25E6%2599%258213%25E5%2588%258637%25E7%25A7%2592.webm

Comment 22

[Makoto Kato [:m_kato]]

Thanks, Sandi.

It seems not to call nsWindow::SetFocus() on your environment. I guess that it depends on Window Manager settings (according to screen cast, it is GNOME shell), but I don't know. (SetFocus is called from nsFocusManager, but why isn't this called?)

Even if nsWindow::SetFocus() isn't called, https://searchfox.org/mozilla-central/source/widget/gtk/nsWindow.cpp#3917-3923 sets gFocusWindow. So then key event is dispatched, but IM event isn't dispatched.

Comment 23

[Sandi Vujaković [:elsandosgrande]]

So… This doesn't seem to be caused by GNOME Shell, but by some configuration entry, but I have no clue which one could even potentially cause this sort of thing, as I said earlier (sorry if I'm becoming repetitive, but it sounded like you were saying that it had something to do with GNOME Shell, which I get the feeling is unlikely given that a clean profile has no issues and said clean profile with my current profile's prefs.js has the issues).

If you think that the verbose output from a clean profile might be of use, I'll share it right away.

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 5/2-5/10)]

Hey, isn't this?

user_pref("focusmanager.testmode", true);

Comment 25

[Sandi Vujaković [:elsandosgrande]]

Well, that does it 😅. I don't recall enabling that in recent time [read: in the past year] though. Hm… I'll try downloading a Nightly build from November from last year to tripple-check.

After trying to look into that preference (I still have no clue what it does), I discovered bug 774892, of which this one might be an extension in some way.

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(PTO: 5/2-5/10)]

It's a pref to run test of our focus manager without OS's focus management. So, it shouldn't be set to true in the real use.

Thank you for reporting and investigating. This conclusion may be same cause of some other bugs.

Comment 27

[Makoto Kato [:m_kato]]

(We may have to output to nsGtkIMModuleWidgets log whether this pref is set).