Is your feature request related to a problem? Please describe.
MouseButton only has Left, Right, Middle (src/event.rs:820). There's no way to detect the X1/X2 (back/forward) mouse buttons that many mice have.
On Unix, this isn't just a missing feature — SGR mouse sequences for X1/X2 currently produce a parse error instead of being ignored or decoded. In parse_cb (src/event/sys/unix/parse.rs:777):
let button_number = (cb & 0b0000_0011) | ((cb & 0b1100_0000) >> 4);
This already computes button_number up to 8/9 for X1/X2 (per the xterm SGR mouse protocol), but the match arm only covers 0-7:
// We do not support other buttons.
_ => return Err(could_not_parse_event_error()),
So a terminal that forwards X1/X2 clicks (e.g. kitty, foot, WezTerm) currently causes crossterm's event parser to error rather than emit an unrecognized-but-harmless event.
Describe the solution you'd like
Add MouseButton::X1 and MouseButton::X2 variants, and decode button numbers 8/9 in parse_cb into Down/Up/Drag(MouseButton::X1|X2) the same way 0-2 are handled today.
MouseButton isn't #[non_exhaustive], so this is a breaking change for any downstream exhaustive match. Given crossterm is pre-1.0, I'd assume that's fine in a minor bump, but wanted to flag it rather than assume - happy to add #[non_exhaustive] as part of this if you'd prefer that over a plain breaking addition.
I've only verified the Unix/SGR path so far. The Windows path (src/event/sys/windows/parse.rs) goes through crossterm_winapi::ButtonState, and I haven't confirmed whether that exposes XBUTTON1/2 - happy to scope this issue/PR to Unix first and follow up on Windows separately if that's cleaner.
Describe alternatives you've considered if any
None at the parser level - X1/X2 has to be decoded here since it's now silently dropped as a hard parse error. Consumers could work around this by binding X1/X2 to a modified keypress in their terminal's own mouse-remap config, but that's a per-user workaround, not something crossterm can rely on generally.
Additional context
Motivating downstream use case: domcyrus/rustnet#274 wants X1/X2 for mouse-driven back/forward navigation between views, and the maintainer confirmed crossterm doesn't currently support this.
I'd like to work on this if the approach above looks reasonable.
Is your feature request related to a problem? Please describe.
MouseButtononly hasLeft,Right,Middle(src/event.rs:820). There's no way to detect the X1/X2 (back/forward) mouse buttons that many mice have.On Unix, this isn't just a missing feature — SGR mouse sequences for X1/X2 currently produce a parse error instead of being ignored or decoded. In
parse_cb(src/event/sys/unix/parse.rs:777):This already computes
button_numberup to 8/9 for X1/X2 (per the xterm SGR mouse protocol), but the match arm only covers 0-7:So a terminal that forwards X1/X2 clicks (e.g. kitty, foot, WezTerm) currently causes crossterm's event parser to error rather than emit an unrecognized-but-harmless event.
Describe the solution you'd like
Add
MouseButton::X1andMouseButton::X2variants, and decode button numbers 8/9 inparse_cbintoDown/Up/Drag(MouseButton::X1|X2)the same way 0-2 are handled today.MouseButtonisn't#[non_exhaustive], so this is a breaking change for any downstream exhaustivematch. Given crossterm is pre-1.0, I'd assume that's fine in a minor bump, but wanted to flag it rather than assume - happy to add#[non_exhaustive]as part of this if you'd prefer that over a plain breaking addition.I've only verified the Unix/SGR path so far. The Windows path (
src/event/sys/windows/parse.rs) goes throughcrossterm_winapi::ButtonState, and I haven't confirmed whether that exposes XBUTTON1/2 - happy to scope this issue/PR to Unix first and follow up on Windows separately if that's cleaner.Describe alternatives you've considered if any
None at the parser level - X1/X2 has to be decoded here since it's now silently dropped as a hard parse error. Consumers could work around this by binding X1/X2 to a modified keypress in their terminal's own mouse-remap config, but that's a per-user workaround, not something crossterm can rely on generally.
Additional context
Motivating downstream use case: domcyrus/rustnet#274 wants X1/X2 for mouse-driven back/forward navigation between views, and the maintainer confirmed crossterm doesn't currently support this.
I'd like to work on this if the approach above looks reasonable.