[Feature Request]: support IME under native Wayland

[Austaras]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for a feature request that matches the one I want to file, without success.

Problem Description

Chrome doesn't support IME under native Wayland before ver 98, and IME only works if gtk-version=4 is enabled after. However when I pass that flag to electron, it would crash saying GTK 2/3 symbols detected. Using GTK 2/3 and GTK 4 in the same process is not supported

Proposed Solution

No idea

Alternatives Considered

No idea too

Additional Information

No response

[harmathy]

For reference: IME refers to something like ibus or fcitx.

[OctopusET]

I'm working on implementing text-input-v3 to chromium. This issue could be solved with this patch.
https://chromium-review.googlesource.com/c/chromium/src/+/3750452

[alariej]

@OctopusET Just to understand what the stand is on Electron/Wayland. Would this patch solve the issues I've listed in this Phosh/squeekboard thread:

https://gitlab.gnome.org/World/Phosh/squeekboard/-/issues/244#note_1581502

[OctopusET]

As far as I know, yes.
Sorry for delays, I didn't have extra time. I think I can restart work soon,
Ref:
https://www.apertis.org/concepts/on-screen-keyboard/

[Silentdoer]

hi, this bug has been fix?

[OctopusET]

@Silentdoer Not yet, I'm currently working on now.

[stalkerg]

@OctopusET do you need help?

[OctopusET]

@stalkerg not now, but could you test it later?

[stalkerg]

@OctopusET sure, one more question - is your chromium patch dependent on gtk4?

[OctopusET]

no it isn't. GTK4 dependent patch is already there.

[stalkerg]

It should be mentioned #33690 here, as I understand, no?

[OctopusET]

@stalkerg chromium source has gtk4 patch but I think it hasn't enabled on electron.
And this patch has some own bugs.

Patch url: https://chromium-review.googlesource.com/c/chromium/src/+/3220698

[OctopusET]

Anyone want to talk about this patch development, please come here.
https://matrix.to/#/#chromium-text-input-v3:matrix.org

[AllanChain]

Just realized that KWin has got text-input-v1 support recently which makes input methods work in Chromium and Electron apps. (https://invent.kde.org/plasma/kwin/-/merge_requests/3403)

[stalkerg]

@AllanChain is correct, and it's good, but it's anyway "deprecated" protocol.

[Silentdoer]

hello, can I ask how you're processing at the moment?

[buresu]

In my environment (KDE Plasma 5.27.10 and fcitx5 5.1.7), the following flag works through text-input-v1.

--enable-wayland-ime

[Kimiblock]

While Kwin supports text-input-v1, the majority of compositors support the v3 variant

[sith-on-mars]

I'm using Gnome and iBus. In Flatpak Chromium putting gtk-version=4 still couldn't get IME working.

[tecix]

I'm using Gnome and iBus. In Flatpak Chromium putting gtk-version=4 still couldn't get IME working.

Try GTK_IM_MODULE=xim XMODIFIERS=@im=ibus google-chrome --gtk-version=4, this works for me.

[sith-on-mars]

I'm using Gnome and iBus. In Flatpak Chromium putting gtk-version=4 still couldn't get IME working.

Try GTK_IM_MODULE=xim XMODIFIERS=@im=ibus google-chrome --gtk-version=4, this works for me.

Didn't work for me unfortunately. This might be a Flatpak specific issue.

[C0rn3j]

@sith-on-mars you can probably put a chromium-flags.conf somewhere into your Flatpak with your desired flags.

[forza91]

i dont know which side can solve this problem, so here is the Gnome repo, pls help to leave a comment or like:
https://gitlab.gnome.org/GNOME/mutter/-/issues/3200

[stalkerg]

@forza91 just in case - IME input for VSCode not working even under KDE.

[forza91]

@forza91 just in case - IME input for VSCode not working even under KDE.

No, bro. Fcitx5 works in KDE Plasma 5.27 with virtual keyboard is on. Native wayland vscode. You can check the previous comment in this thread

[Albrecht0xff]

For vscode and such electron apps, to enable wayland IME support must specify the --enable-wayland-ime flag, However, this is not perfect. Usually we modify the vscode startup script directly, or the .desktop file. These files will be overwritten to the default values when using the package manager to install an updated version.

To enable wayland support, we can directly set the ozone platform hint in the environment variable, which will not be overwritten by the package manager.

However, currently just to enable the wayland input method, every time the app updates to a newer version, i will have to modify the startup script again.

Could we just add a feature that can detect the platform hint environment variable and enable wayland ime by default if the platform hint is wayland or simply add another environment variable called ELECTRON_ENABLE_WAYLAND_IME?

[teohhanhui]

Usually we modify the vscode startup script directly, or the .desktop file. These files will be overwritten to the default values when using the package manager to install an updated version.

You make a local copy of the desktop file in ~/.local/share/applications. You should never modify non-config (/etc) files installed by the package manager.

[Albrecht0xff]

Usually we modify the vscode startup script directly, or the .desktop file. These files will be overwritten to the default values when using the package manager to install an updated version.

You make a local copy of the desktop file in ~/.local/share/applications. You should never modify non-config (/etc) files installed by the package manager.

Thanks, I forgot that Desktop Entry can be overwritten:

ArchWiki:
User entries take precedence over system entries.

[Kimiblock]

Just a notice: this workaround requires a compositor supporting text-input-v1, which GNOME's mutter and many other compositors lack or have problematic implementations.

[xuanruiqi]

Yeah, this is a non-solution, not even a workaround. It's just utilizing a feature that Electron already has. Nevertheless, the maintainers of Visual Studio Code really could do nothing about this (besides trying to patch, or even better, send PRs to, Electron), as the problem clearly lies with Electron, and is a systematic issue without easy workarounds.