Fix ESCAPE key processing with web_driver under Windows #6031
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes gh-5969.
Summary
gh-5969 reports that running ESC key presses are not processed immediately when running textual in the web under Windows. This is due to the
InputReader
under Windows performing a blocking read without honouring the timeout. This PR fixes theInputReader
, which in turn fixes gh-5969.Checklist
Docstrings on all new or modified functions / classesUpdated documentationUpdated CHANGELOG.md (where appropriate)Remarks
An
InputReader
is used by the web driver of the launched app to read user input fromstdin
, which is redirected to an anonymous pipe under Windows. Unlike Linux, anonymous pipes under Windows support just a limited set of operations: (blocking) read, (non-blocking) peek, and close. In particular, the OS provides no way toselect
/wait
an anonymous pipe, perform asynchronous read, or interrupt/cancel a blocking read.Therefore, to support read with timeout, this PR creates a background thread to read from the pipe and pass on the data through a
Queue
to the thread where theInputReader
is iterated. Timeout is achieved viaQueue.get()
.While this workaround is straightforward, it does have a semantic difference from the
InputReader
under Linux: the background thread reads data in advance of being iterated. This is not a problem for Textual because only oneInputReader
instance is created and it is used throughout the lifetime of the app. However, the implementation is not suitable for general use.An alternative (not pursued by this PR) could be to redirect
stdin
to a named pipe under Windows, which supports timeout and asynchronous operations. That requires making changes in thetextual-serve
repo in addition to this one.