Japanese input doesn't work in chromium/chrome browsers under Wayland

[jaro3]

Latest Gnome on Wayland - chrome, chromium, brave ... all have the same issue when in native Wayland mode (flag --ozone-platform-hint=auto/wayland) even when the flag --gtk-version=4 is present ;-; Firefox and other applications work fine....

ibus-mozc 2.29.5250.102-1
mozc-ut 2.29.5250.102.20231011-1
gnome-shell 1:45.0-1
google-chrome 118.0.5993.70-1

[kenkenspin]

the same problem.

Fedora Linux Workstation 40
ibus-mozc 2.29.5111.102-8
gnome-shell-46.1-1
google-chrome-stable-124.0.6367.91-1

[yukawa]

I understand your frustrations but in general your problems cannot be solved in the Mozc side.

IMHO the most realistic solution would be adding text_input_v1 support to mutter as requested in the following thread.

• https://gitlab.gnome.org/GNOME/mutter/-/issues/3200

See also the following comment as for why this happens in Chromium-based browsers but not in Firefox.

• https://invent.kde.org/plasma/kwin/-/merge_requests/3403#note_593116

Some additional information that why this is necessary for chrome instead of waiting for them to add text-input-v3 support.

I personally talked with some chrome people who's working on this and they feel reluctant to change to text-input-v3 since they don't find it meet their use case and chrome also use this v1 protocol internally for chrome OS. So for foreseeable future I don't expect they to adopt any new text-input version.

And due chrome's graphical stack design, they can't just get gtk's text-input-v3 from gtk im module because the window in chrome is not managed by gtk, which is a necessity to make gtk's wayland im module work properly. (on the contrary, firefox uses native gtk window so it gets text-input-v3 easily from gtk)

In summary, supporting text-input-v1 in compositor is the easiest route to bring a workable input method with native wayland chrome(and electron).