wl: a content purpose belongs to its activation

pendingpurpose was never cleared, and sway sends content_type only when
the text input asked for one: active_features is frozen at the enable
commit (wlr_text_input_v3.c) and relay_send_im_state tests it before
sending.  So a client that sets no content type leaves the last client's
purpose standing -- and after a GTK password entry that purpose is
password, so every key in the next window was forwarded raw and strans
looked dead there until a client that does declare one took the focus.

A purpose is per activation, as it is per context in ibus.c.  Clearing it
on activate is enough: the content type, if any, arrives after the
activate and before the done that applies both.

The sway runs could not have found this; the password client was GTK,
which always declares.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
2026-08-17 21:21:24 +09:00
parent 40fd4ab551
commit 6d511919e8

6
wl.c
View File

@@ -387,11 +387,17 @@ flushpending(void)
takedraw(); takedraw();
} }
/*
* A purpose belongs to the activation: the compositor sends a content type
* only for a client that asked for one, so a client that asks for none has
* none, whatever the last one wanted.
*/
static void static void
imactivate(void*, struct zwp_input_method_v2*) imactivate(void*, struct zwp_input_method_v2*)
{ {
pendingactive = 1; pendingactive = 1;
activated = 1; activated = 1;
pendingpurpose = 0;
} }
static void static void