IBus text injection is a silent no-op on GNOME/Mutter Wayland (reports success, nothing typed)

[fsioni]

Summary

On GNOME/Mutter Wayland, IBus text injection is a silent no-op: the Vocalinux IBus engine activates, commit_text() reports success and IBusTextInjector.inject_text() returns True, but the text never reaches the focused application. Because _check_dependencies() prefers IBus whenever it is the active input method, Vocalinux never falls back to ydotool/wtype, so dictation silently disappears into the void with no error.

Environment

• OS: Ubuntu 24.04 (noble)
• Desktop: GNOME on Wayland (XDG_CURRENT_DESKTOP=ubuntu:GNOME, Mutter)
• QT_IM_MODULE=ibus, XMODIFIERS=@im=ibus (so is_ibus_active_input_method() returns True)
• ibus-daemon running; Vocalinux engine reachable over its socket

Steps to reproduce

1. GNOME Wayland session with IBus active (the default on Ubuntu).
2. Focus any text field and dictate.
3. Nothing is inserted, and the log shows the IBus path "succeeding".

Evidence

Minimal end-to-end test: a GTK Entry is shown and grabs focus, then the Vocalinux IBus client injects into it.

inj = IBusTextInjector()
inj.prepare_engine()
ok = inj.inject_text("Bonjour, accents: éàç ù €")
# logs:
#   INFO Activating Vocalinux IBus engine...
#   INFO Vocalinux IBus engine activated
#   INFO Starting IBus text injection: 'Bonjour, accents: éà...'
print(ok)                  # -> True
print(repr(entry.get_text()))  # -> ''  (the focused field received NOTHING)

ibus engine vocalinux does switch the active engine successfully (the engine registers dynamically via register_component(), so it is not listed by ibus list-engine but can still be activated). Despite that, commit_text() from the engine instance does not land in the focused client on Mutter.

Why it matters

_check_dependencies() deliberately prefers IBus when it is the active input method:

# Prefer IBus on both X11 and Wayland - it sends Unicode directly,
# bypassing keyboard layout issues entirely
if is_ibus_available():
    if not is_ibus_active_input_method(): ...
    ...
    self._ibus_injector = IBusTextInjector(...)
    ibus_requested = True

On GNOME Wayland (the largest Linux desktop) IBus is the active input method by default, so this is the path most users hit — and it injects nothing while reporting success. The existing runtime fallback (_switch_to_non_ibus_backend) only triggers when IBus injection returns False, which never happens here.

Possible directions (happy to help / open a PR)

1. Verify IBus injection actually delivered, and fall back to ydotool/wtype when it didn't (hard to do reliably — commit_text gives no delivery confirmation).
2. Prefer a working ydotool daemon over IBus when one is available (uinput-level injection bypasses the compositor's IM integration entirely). I'm running this locally as a small guard around _start_ibus_initialization() and it fixes injection on this setup — but it reverses the current "prefer IBus" design, so it needs a maintainer decision.
3. Detect Mutter specifically and de-prioritise the IBus path there.

Note: the layout/clipboard reliability bugs that this interacts with are addressed separately in #480; this issue is specifically about the silent IBus no-op and backend-selection policy.

Happy to turn whichever direction you prefer into a PR.

[fsioni]

Closing as a duplicate of #478, which describes the same IBus silent-no-op with a sharper root-cause analysis (bare xkb:* engine → commit_text() reaches no app).

I've moved the GNOME/Mutter-specific nuance over to #478: on GNOME the false positive comes through the QT_IM_MODULE=ibus env-var check rather than the daemon fallback, so the guard proposed there needs to apply regardless of how "ibus active" was detected.

The related clipboard + ydotool non-US-layout reliability fixes are in #480, and the setxkbmap-rewrites-XWayland-to-us side effect is tracked in #474.