Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Key bypasses read_key() when more than one key pressed together #152

Open
NilVentosa opened this issue Jan 3, 2023 · 7 comments
Open

Key bypasses read_key() when more than one key pressed together #152

NilVentosa opened this issue Jan 3, 2023 · 7 comments
Labels

Comments

@NilVentosa
Copy link

First of all thanks for creating this crate :)
I am having an issue that when I am using read_key() and press more than one character key at the same time, sometimes one of them bypasses the method and is written to the terminal.
For example with the following code:

loop {
    let term = Term::stdout();
    if let Key::Char(thing) = term.read_key().unwrap() {
            term.write_line(&format!("{}", style(" thing").green().bold()))?;
    }
}

if I press j and k at the same time the output is something like:

 thing
 thing
 thing 
k thing
 thing
k thing
 thing
j thing

Not sure if I am using it wrong or if there is an issue here.
Thanks!

@mitsuhiko
Copy link
Collaborator

On which terminal and operating system are you experiencing this behavior?

@mitsuhiko mitsuhiko added the bug label Jan 3, 2023
@NilVentosa
Copy link
Author

NilVentosa commented Jan 3, 2023

zshell in iTerm 2 in macos

@mitsuhiko
Copy link
Collaborator

So my guess of what's happening is that read_key moves the terminal into and out of raw mode for each key press. It is probably a race condition of what happens when more than one key is pressed at the same time. In that case sometimes the key might end up in non raw mode.

Unfortunately that is not really solvable unless console provides an API to switch the entire terminal into raw mode. That however is quite likely platform specific and I'm not sure if that can be abstracted over in a reasonable way. It might be, but I would need to experiment with that.

@NilVentosa
Copy link
Author

Thanks for the quick answer and review!

@fadeevab
Copy link
Contributor

fadeevab commented Jun 29, 2023

The same bug on WSL2 with bash in Ubuntu under Windows Terminal application in the VSCode integrated terminal.

@fadeevab
Copy link
Contributor

fadeevab commented Jul 1, 2023

@mitsuhiko The bug is sometimes nasty when you're playing with custom interface rendering e.g. password hidding and the real character suddenly appears somewhere in the terminal cursor. The fix could be like introducing a manual enabling/disabling the raw mode and something like get_key_raw which doesn't switch the raw mode back and forth.

@george-cosma
Copy link

I can confirm that this still happening. As said previously, the likely cause is this race condition. For me it happens only under a VM, in VSCode integrated terminal (so a lot of overhead!). I first noticed this when holding down the left arrow key - the OS(?) starts queueing up the key a whole lot faster the longer you hold it, and so the race condition happens quite a lot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants