Repository navigation
Double keypress in readline / process.stdin #25875
Description
Activity
@nodejs/libuv @nodejs/repl
- addedreadlineIssues and PRs related to the built-in readline module.Issues and PRs related to the built-in readline module.libuvIssues and PRs related to the libuv dependency or the uv binding.Issues and PRs related to the libuv dependency or the uv binding.
on Feb 1, 2019 - addeddocIssues and PRs related to Node.js documentation.Issues and PRs related to Node.js documentation.and removedlibuvIssues and PRs related to the libuv dependency or the uv binding.Issues and PRs related to the libuv dependency or the uv binding.
on Feb 1, 2019 @Ezekiel-DA Can you try changing that logging line to use
chunk.toString('hex')and comment with the output?I get:
Received 3 bytes of data - content was: 1b5b42The libuv change
* tty,win: fix Alt+key under WSL (Bartosz Sosnowski)seems suspect to have changed that on your system.
However, I am quite sure this is not a bug.
The
'data'event you are listening to is fromprocess.stdinitself and it's intention is to emit data events as the stdio connection passes them. This is not what you should be using, but I can't blame you - the documentation for what you should be using is actually missing completely.Node.js internally uses this functionality to condense stdio connection events into what we would expect -- keypresses.
That isn't directly exposed but is used in
readline.emitKeypressEvents(), which is automatically used onreadlinewhen attached to a Pipe or a Raw-mode TTY (terminal). The events are emitted off of the stream (rl.input), though, for some reason.The resulting output from the
'keypress'and the down arrow key looks like this:[Arguments] { '0': undefined, '1': { sequence: '\u001b[B', name: 'down', ctrl: false, meta: false, shift: false, code: '[B' } }... I don't really know why this event is emitted where it is and why it is not documented, but this is what you should use, I think.
@Fishrock123 Thanks for looking into this! The only reason I listen to 'data' is to try and find a minimal reproduction for a change in behavior that impacts Inquirer (see SBoudrias/Inquirer.js#778) and appeared when libuv was upgraded to 1.25.0.
I'm pretty sure I found the source of the problem in libuv, and I opened libuv/libuv#2168. As you can see there, the specific scenario of Windows, special keys (e.g. down arrow here) hits a regression that produces an even for both key down and key up, which I'm pretty sure is not the desired behavior!
- addedlibuvIssues and PRs related to the libuv dependency or the uv binding.Issues and PRs related to the libuv dependency or the uv binding.
on Feb 2, 2019 As a data point, I can also reproduce this issue and has been happening since last Node.js upgrade (Windows 10 x64 1809).
Word on the street is that libuv/libuv#2160 will fix the issue.
Reacted by Ezekiel-DAReacted by Fabio Pintos, antsmartian and Nico Jansen- added 2 commits that reference this issue
on Feb 10, 2019 - added a commit that references this issue
on Feb 13, 2019 - added a commit that references this issue
on Feb 13, 2019 - added a commit that references this issue
on Apr 5, 2019 - added 2 commits that reference this issue
on May 16, 2019 - added a commit that references this issue
on Jul 23, 2025 - added a commit that references this issue
on Dec 16, 2025
This code produces repeated output:
Run this with Node 11.8.0 or above and press the down arrow; two messages are produced:
Revert to Node 11.7.0, a single message is produced.
This breaks, among many things, scrolling through menus in Inquirer.js: SBoudrias/Inquirer.js#778
This appears to be Windows specific (as far as I could tell, I was only able to test on a Linux VM via Docker right now).
Git bisect tells me this issue first appeared with c0859d7, which upgraded
libuvto1.25.0.I'll keep digging into libuv (I already have an idea of where the problem was introduced in 1.25.0) but since this impacts Node on Windows somehwat significantly I figured it would be useful to have a way to track this!