X11: `KeyboardInput` events with `ElementState::Released` are leaked during IME composition with Fcitx5

[umajho]

Description

Although KeyboardInput events with ElementState::Pressed are not emitted, the ElementState:: Released counterparts are emitted.

I have only tested on Fcitx5. I don't know whether other IMFs (e.g. IBus) under X11 also have this problem.

The ideal behavior should look like the Wayland + IBus one demonstrated in #4508.

Reproduction

https://gist.github.com/umajho/5f42a9cfe49ecfe61d4a9753796d00f2

OS and window mananger

Debian 13
Cinnamon 6.4.10
Fcitx5 5.1.2

Winit version

0.30.13

[kchibisov]

Can you show full event data from winit?

[umajho]

Due to time zone differences, I'll provide a complete log of all events tomorrow (in 24 hours).
Apologies for the delay.

[umajho]

Hello.
I recorded the typing of “测试” (ceuiSpace) again, this time with all events fully logged.

Full log: https://gist.github.com/umajho/da5f3cc132a5a1f2c14e852ac4d86892

The following lines (507~523) in the log appear to be the relevant ones:

[5.155965628][device_event] Key(RawKeyEvent { physical_key: Code(KeyC), state: Pressed })
[5.234065711][device_event] Key(RawKeyEvent { physical_key: Code(KeyC), state: Released })
[5.236917336][window_event] KeyboardInput { device_id: DeviceId(X(DeviceId(3))), event: KeyEvent { physical_key: Code(KeyC), logical_key: Character("c"), text: Some("c"), location: Standard, state: Released, repeat: false, platform_specific: KeyEventExtra { text_with_all_modifiers: Some("c"), key_without_modifiers: Character("c") } }, is_synthetic: false }
[5.370160503][device_event] Key(RawKeyEvent { physical_key: Code(KeyE), state: Pressed })
[5.449910794][device_event] Key(RawKeyEvent { physical_key: Code(KeyE), state: Released })
[5.453943753][window_event] KeyboardInput { device_id: DeviceId(X(DeviceId(3))), event: KeyEvent { physical_key: Code(KeyE), logical_key: Character("f"), text: Some("f"), location: Standard, state: Released, repeat: false, platform_specific: KeyEventExtra { text_with_all_modifiers: Some("f"), key_without_modifiers: Character("f") } }, is_synthetic: false }
[5.496106461][device_event] Key(RawKeyEvent { physical_key: Code(KeyU), state: Pressed })
[5.55596242][device_event] Key(RawKeyEvent { physical_key: Code(KeyI), state: Pressed })
[5.60372967][device_event] Key(RawKeyEvent { physical_key: Code(KeyU), state: Released })
[5.605956836][window_event] KeyboardInput { device_id: DeviceId(X(DeviceId(3))), event: KeyEvent { physical_key: Code(KeyU), logical_key: Character("l"), text: Some("l"), location: Standard, state: Released, repeat: false, platform_specific: KeyEventExtra { text_with_all_modifiers: Some("l"), key_without_modifiers: Character("l") } }, is_synthetic: false }
[5.681663711][device_event] Key(RawKeyEvent { physical_key: Code(KeyI), state: Released })
[5.68287692][window_event] KeyboardInput { device_id: DeviceId(X(DeviceId(3))), event: KeyEvent { physical_key: Code(KeyI), logical_key: Character("u"), text: Some("u"), location: Standard, state: Released, repeat: false, platform_specific: KeyEventExtra { text_with_all_modifiers: Some("u"), key_without_modifiers: Character("u") } }, is_synthetic: false }
[5.962378378][device_event] Key(RawKeyEvent { physical_key: Code(Space), state: Pressed })
[5.965989128][window_event] Ime(Preedit("", None))
[5.965995586][window_event] Ime(Commit("测试"))
[6.061632253][device_event] Key(RawKeyEvent { physical_key: Code(Space), state: Released })
[6.063128003][window_event] KeyboardInput { device_id: DeviceId(X(DeviceId(3))), event: KeyEvent { physical_key: Code(Space), logical_key: Named(Space), text: Some(" "), location: Standard, state: Released, repeat: false, platform_specific: KeyEventExtra { text_with_all_modifiers: Some(" "), key_without_modifiers: Named(Space) } }, is_synthetic: false }

(The mismatch in characters within KeyboardInput is due to my default keyboard layout being Colemak, while the Chinese IME uses the QWERTY layout. It appears that winit still interprets the input as Colemak.)

3.4 MB screencast

[kchibisov]

Hm, seems like your IME decided not to ignore them. We can try to detect and drop them in winit, I guess, but usually IME should consume them.

[umajho]

I read through the source code, and it appears that it already filters “all of the KeyPress events in compose/pre-edit sequences, along with an extra copy of the KeyRelease events”:

winit/src/platform_impl/linux/x11/event_processor.rs

Lines 131 to 144 in e9809ef

	/// XFilterEvent tells us when an event has been discarded by the input method.
	/// Specifically, this involves all of the KeyPress events in compose/pre-edit sequences,
	/// along with an extra copy of the KeyRelease events. This also prevents backspace and
	/// arrow keys from being detected twice.
	#[must_use]
	fn filter_event(&mut self, xev: &mut XEvent) -> bool {
	let wt = Self::window_target(&self.target);
	unsafe {
	(wt.xconn.xlib.XFilterEvent)(xev, {
	let xev: &XAnyEvent = xev.as_ref();
	xev.window
	}) == xlib::True
	}
	}

There is also a comment later noting that “in compose/pre-edit sequences, we'll always receive KeyRelease events.”:

winit/src/platform_impl/linux/x11/event_processor.rs

Lines 197 to 206 in e9809ef

	// Note that in compose/pre-edit sequences, we'll always receive KeyRelease events.
	ty @ xlib::KeyPress | ty @ xlib::KeyRelease => {
	let state = if ty == xlib::KeyPress {
	ElementState::Pressed
	} else {
	ElementState::Released
	};
	self.xinput_key_input(xev.as_mut(), state, &mut callback);
	},

However, it doesn't seem to explain the rationale behind this behavior (“why the original KeyRelease events are preserved”).

---

That said, since I haven't identified any scenarios where this behavior would cause issues, I don't consider this to be a high-priority problem.