input: Driver.Cancel Doesn't Work On Windows

[CannibalVox]

Describe the bug
A clear and concise description of what the bug is.

The Input package has a Driver type that has a ReadEvents method and a Cancel method that seems like it is supposed to cause in-flight ReadEvents calls to die and return an error. This does not work on Windows, because the underlying engine of ReadEvents is the github.com/erikgeiser/coninput ReadConsoleInput method, whose underlying engine is Windows' ReadConsoleInputW syscall. This syscall has no cancellation or timeout mechanism and will hang forever until it receives some sort of input.

Setup
Please complete the following information along with version numbers, if applicable.

• OS Windows 10
• Shell Windows CMD
• Terminal Emulator Windows Terminal

To Reproduce
Steps to reproduce the behavior:

1. Attempt to retrieve background color with lipgloss v2

Source Code
lipgloss v2's standalone color example

Expected behavior
Either retrieving the background successfully or time out

[CannibalVox]

After digging around a bit:

• The windows Driver seems to be built to specifically handle key and mouse input only, with the idea that full blocking on a goroutine waiting for that stuff makes sense
• Unfortunately, non-windows Driver handles EVERYTHING. Calling the Driver with an ANSI query will inevitably work on non-windows and fail on windows
• The windows CancelReader seems to handle everything appropriately (? not sure on this) but nothing actually calls the windows CancelReader. The stdin handle is used by ReadConsoleInput, but the methods are not ever actually called. This seems like an issue.

[CannibalVox]

I have verified locally that removing the windows-specific code for Driver.ReadEvents fixes this issue (and also successfully retrieves the background color in the preview version of windows terminal) but I don't know what knock-on consequences that might have elsewhere. I see that bubbletea v2 has its own version of this code and has a readInputs method that calls ReadEvents and I suspect that that code actually intends to call the blocking ReadConsoleInput method, so I imagine that both are necessary.

[aymanbagabas]

Hi @CannibalVox, thank you for reaching out and reporting this issue. Indeed, Bubble Tea has its own version of x/input. We're planning on deprecating x/input since the code moved to Bubble Tea v2.

As for the issue, I suspect the problem was due to this hack. You see, when using the Windows Console API instead of their Virtual Terminal mode (the default), we need to parse escape sequences as if they were key events. The code in x/input is outdated and sometimes won't correctly read the responses. This was fixed in charmbracelet/bubbletea#1163. We need to not use the Virtual Terminal input mode so that we can read window resize events and extended keyboard/mouse events.

I've opened charmbracelet/lipgloss#429 to fix this issue in Lip Gloss.

[CannibalVox]

Thank you! I've confirmed that the linked PR fixes the issue:

• Standalone CMD does not hang and returns a nil background color immediately
• CMD hosted in Windows Terminal does not hang and returns a nil background color immediately
• MINGW hosted in Windows Terminal does not hang and returns a nil background color immediately
• CMD hosted in Windows Terminal Preview returns the correct background color
• MINGW hosted in Windows Terminal Preview returns the correct background color