xrdp_input_enable() unconditionally reasserted XrdpIme as the global
engine any time it wasn't already active, on the theory that ibus can
silently revert to the user's original engine on its own. That's true,
but the fix was too broad: it also fired whenever the user had
manually switched the session's engine to something else entirely
(e.g. libpinyin, to compose Chinese directly in the remote desktop
rather than via the client's local IME), yanking control away
mid-use. Confirmed happening live: a composition left pending in a
client-side IME and then abandoned got auto-flushed by the OS well
after the fact, silently reclaiming XrdpIme and interrupting an
unrelated libpinyin session already in progress.
Now only reclaims XrdpIme when the current engine is unset or matches
the original one remembered before ever switching away from it
(last_input_name) - the actual "ibus reverted on its own" case this
existed for. Any other named engine is treated as a deliberate choice
and left alone; the stale/deferred commit is dropped instead of
hijacking whatever the user is currently doing.
Also fixes a hang found while testing this: if xrdp_input_unicode_init()
times out waiting for ibus_get_address() (daemon unreachable), it
returned early without resetting ibus_thread_exited back to TRUE, even
though it had just set it FALSE in anticipation of a thread that was
never actually created. No thread means no broadcast ever comes, so
any later xrdp_input_unicode_destroy() or re-init() call blocks on
that condvar forever. Pre-existing in the private-loop rewrite, not
introduced by this change - just surfaced by testing this one harder.
Verified: 20 back-to-back init() calls on a healthy connection still
take the fast path with no false failures; manually switching to a
different engine and then sending a stale commit leaves that engine
untouched and fails the commit; reverting to the original engine still
correctly reasserts XrdpIme; 5 kill/restart cycles still show no
thread leak; an 18-char rapid-fire send against a real focused GTK
entry still lands every character in order.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Liyi Meng
82b4eb6556