event::read incorrectly returns Esc key press event while scrolling the mouse wheel

[unixzii]

Describe the bug
event::read sometimes returns Esc key press event while scrolling the mouse wheel very fast. This will likely happen on macOS if the user is using a trackpad (which can produce high frequency events because of the inertia simulation).

Precondition:
The terminal is in a mode that translates mouse wheel events into arrow key events.

To Reproduce
The minimal reproducible example:

use anyhow::Result;
use crosstermion::terminal::AlternateRawScreen;

fn main() -> Result<()> {
    // Help to get into alternative screen mode, this should not
    // affect the final result.
    let _alt_screen = AlternateRawScreen::try_from(io::stderr())?;

    while let Ok(event) = crossterm::event::read() {
        match event {
            crossterm::event::Event::Key(key) => {
                if key.code == crossterm::event::KeyCode::Esc {
                    panic!("wrong event received");
                }
            }
            _ => {}
        }
    }
}

Steps to reproduce the behavior:

1. Build and run the example program.
2. Scroll very fast using the trackpad (or Logitech MX Master mouse, which will also work).
3. See the program panic.

Expected behavior
The program should not receive Esc key press events when the user didn't press Esc key.

OS
Verified on macOS 13.6

Terminal/Console

• Warp
• Visual Studio Code terminal

[unixzii]

I noticed that the parser parsed Esc key press because the tty buffer is insufficient.

The byte sequence read from stdin in one poll ends with 27, which is cut off. Maybe there are some bugs in the terminal emulator that the control sequence is not written atomically. Or the operating system doesn't give us the whole buffer at once.