Open Bug 1701047 Opened 1 month ago Updated 24 days ago

Ibus IMEs and the compose key not functional in Firefox

Categories

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

x86_64
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: sandyvujakovicj, Unassigned)

Details

(Keywords: inputmethod, regressionwindow-wanted)

Attachments

(3 files)

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.

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.

Component: Untriaged → DOM: UI Events & Focus Handling
Product: Firefox → Core

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?

Severity: -- → S1
Flags: needinfo?(sandyvujakovicj)
Keywords: inputmethod
OS: Unspecified → Linux
Hardware: Unspecified → x86_64

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

Attached image Exit code 11

So…

Attached file Output log
Attached image 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).

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

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.

Flags: needinfo?(sandyvujakovicj)
QA Whiteboard: [qa-regression-triage]
You need to log in before you can comment on or make changes to this bug.