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

Unable to detect when key is being held down in crossterm #15124

Closed
lesleyrs opened this issue Apr 6, 2023 · 3 comments
Closed

Unable to detect when key is being held down in crossterm #15124

lesleyrs opened this issue Apr 6, 2023 · 3 comments
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.

Comments

@lesleyrs
Copy link

lesleyrs commented Apr 6, 2023

Windows Terminal version

1.16.10261.0

Windows build number

10.0.19045.0

Other Software

Crossterm crate https://crates.io/crates/crossterm 0.26.1 latest

Steps to reproduce

Crossterm is a terminal library that recently added the ability to detect when a key is being held down and released.

On both conhost and wezterm this works as intended. In the crate if you run cargo run --example event-poll-read in both of these terminals it will correctly show input.

While on windows terminal for keys that produce letters it will just send "released" right after "pressed". Some other keys like arrow keys and tab do work correctly though.

This is not only a lack of functionality but can also create some weird side effects by keys being released unintentionally.

Expected Behavior

Example of conhost correctly registering key presses and only release when released:

image

Actual Behavior

In windows terminal it looks like:

image

@lesleyrs lesleyrs added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Apr 6, 2023
@lesleyrs
Copy link
Author

lesleyrs commented Apr 6, 2023

Just to be clear it's not just me with this issue, most people using crossterm fixed it by only checking for key press OR release. But that doesn't fix the problem.

@DHowett
Copy link
Member

DHowett commented Apr 6, 2023

Hey, thanks for the excellent repro! We're actually tracking this over in /dup #8440, and it's blocked on the Windows input subsystem Terminal is using (it doesn't give us as much fine-grained info as the old Windows Console one). Really sorry about that! Please subscribe over there for updates. 😄

@microsoft-github-policy-service
Copy link
Contributor

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

@microsoft-github-policy-service microsoft-github-policy-service bot added Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Apr 6, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue-Bug It either shouldn't be doing this or needs an investigation. Resolution-Duplicate There's another issue on the tracker that's pretty much the same thing.
Projects
None yet
Development

No branches or pull requests

2 participants