isprivate() reads the GTK input purpose and nothing else, but the purpose
is not the only way an application marks a password field, and it is not
the older one. GTK 3.24.52, measured:
gtk_entry_set_visibility(entry, FALSE) purpose stays FREE_FORM
gtk_entry_set_input_purpose(PASSWORD) purpose PASSWORD
so an entry hidden the first way looks like ordinary text to the module.
This machine runs one. /usr/libexec/xfce-polkit, the XFCE authentication
dialog, is up right now under GTK_IM_MODULE=strans, and its binary calls
gtk_entry_set_visibility and never gtk_entry_set_input_purpose, so every
password typed into it goes through the engine. Against the real daemon,
in Korean mode:
typed hunter2 stored ㅗㅕ숟ㄱ2
typed correcthorse stored 책ㄱㄷㅊ쇅ㄴㄷ
typed P4ssw0rd stored ㅔ4ㄴㄵ0ㄱㅇ
The field draws bullets, so nothing on screen says why the authentication
failed -- except the pending syllable, which is drawn as itself: three
keys into such an entry the old module leaves 한 on screen where the
field should read ●●●. With this it reads ●●●, and the entry holds gks.
set_visibility sends the input context no signal, so the question cannot
be answered where the purpose is, in init and notify::input-purpose. It
has to be asked at the key, of the client window, which is the entry's
own: gdk_window_get_user_data on it returns the GtkEntry. fcitx5-gtk asks
it the same way in all three of its GTK versions -- gtk3/fcitximcontext
.cpp:1155-1162, under the comment "seems visibility != PASSWORD hint".
It costs one field read and one type check per key, on a path that then
does a socket round trip anyway. It does not cover XIM: that protocol has
no attribute for this, and no fcitx5 frontend answers it either -- only
its GTK and Qt client modules do -- so an X client reached over XIM still
composes in its password field. Nor does it notice a "show password" box
switched off in the middle of a composition: there is no signal for
visibility, so the pending text stays in the daemon until the next focus
change. Noticing that needs a signal connection on a widget the module
does not own, which is a bigger thing than the hole is.
The test is a live one and it earns its line: with the fix removed it says
gtk_live_test: hidden-entry key reached daemon or did not commit
Both guards were checked by removing them. Without GTK_IS_ENTRY the run
takes a Gtk-CRITICAL and fails; without the im->win test it exits 139, on
the stalled-peer context, which never gets a client window. An ishidden
that always answers yes fails earlier still, at the initial protocol
frames. Breaking the test's own helper so it hands back the toplevel's
window instead of the entry's fails too, which is what says the assertion
watches the right window rather than merely counting no events.
That count is the one thing that had to be made deterministic. A new
client window invalidates the caret, and the fake daemon records that
frame on its own thread, so sampling the event count straight after
set_client_window raced it: 2 failures in 8 runs. The block now waits for
that frame and names it, and there were 0 in 20 after.
90 unit, check-live, check-stress and valgrind clean.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
GtkIMContextSimple composes dead keys, and while it did the daemon still
held the syllable typed before them: the composed é was inserted first
and 하 reappeared after it. A key the daemon does not take now resets
the composition when Simple begins composing on it — a modifier press,
which is also no key, leaves it alone.
Clicking elsewhere, changing focus, or any client reset dropped the
composition in the GTK module and IBus (only XIM ResetIC handed it
back), so typing 안녕 and clicking Send lost 녕. The engine now returns
the pending text — a moved-to candidate first, as Enter would — on
Keyreset and Keyrelease; the GTK module asks for it before closing on
focus-out and commits it, IBus commits it on FocusOut, Reset and a
switch to a password field, and XIM commits it on focus loss and hands
it back on ResetIC without a separate capability probe.
ipc.c: an AF_UNIX nonblocking connect completes at once or fails with
EAGAIN, so the EINPROGRESS/poll/SO_ERROR path and the fcntl juggling
were dead; the deadline plumbing checked a clock that cannot fail and
re-tested the deadline before every transfer although only waitfd
blocks; readfield's truncation and discard loop served the unit test,
since every caller owns char[Ipcfieldmax+1]; NULL-argument checks on
in-tree encoders are gone (peer validation stays). The primary key frame
is Ipckey, not 'legacy'; ipckeysym names the keysym mapping.
srv.c: the per-connection capability and caret already lived in the
persistent Keyreq; the mirror locals and 'negotiated' flag guarded a
protocol rule no client relied on. proccreate never fails in libthread.
gtk: focus-out no longer round-trips a reset before closing the socket
that releases the engine; the caret dedup compares the packed frame;
srvconnect's preedit no-ops and the insimple flag are gone.
The keysym-to-engine-key rule lived in ibus.c, xim/xim.c and gtk/main.c,
and the copies disagreed: GTK sent keypad digits as special keys while
IBus and XIM sent '1'..'9'. Modifiers were rebuilt bit by bit in two
places although Mmask already is the X core layout; only the virtual
Super bit (26) that GDK and IBus set needs folding. ipckey/ipcmod in
ipc.c serve the daemon, the module and the tests.
The GTK IM module only emitted the commit signal when the key was
eaten (r != 0). But when a non-matching key is pressed mid-composition
the engine commits the pending preedit and returns eaten=0 so the raw
key passes through, sending a commit string with eaten=0. GTK dropped
it, silently losing the composed text (e.g. Hangul "ㅇ" + "?" yielded
only "?").
Commit whenever a commit string is present, matching the wayland, ibus
and xim frontends.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
