process.stdin keypress event returns ctrl: false in a [control + [backspace] event

[dthree]

When logging a keypress event, the [control] key generally provides a { ... ctrl: true } in the return keypress data returned on the event. However, peculiarly, when [control + [backspace] event is fired, ctrl is returned as false.

Steps to reproduce:

var rl = require('readline');

var i = rl.createInterface(process.stdin, process.stdout, null);
i.question("What do you think of node.js?", function(answer) {
  console.log("Thank you for your valuable feedback.");
  i.close();
  process.stdin.destroy();
});

process.stdin.on('keypress', function(key, data){
  console.log(data);
});

/*
  { sequence: ',
  name: 'backspace',
  ctrl: false,        < -- should be true
  meta: false,
  shift: false }
*/

This was verified to be a situation in v4.0.0.

[Fishrock123]

Afaik, you'll need to put the readline into terminal mode for this? https://github.com/nodejs/node/blob/master/lib/readline.js#L124

I don't think process.stdin itself does this. Weirdly enough, Readline emits events on it's input stream.

[dthree]

Ah. Got it. Tried terminal mode as such, to the same result:

var i = rl.createInterface({
  input: process.stdin,
  output: process.stdout, 
  terminal: true 
});

It's literally the control + backspace combination. For example, control + d or any other character returns the correct object, terminal mode or not. Can't find where in readline the event object is assembled, however.

Any ideas?

[dthree]

Looks like the emitKeys function might have something funky:

https://github.com/nodejs/node/blob/master/lib/readline.js#L984

[dthree]

Looks like control isn't computed for backspace

} else if (ch === '[') {
...
// Parse the key modifier
key.ctrl = !!(modifier & 4);
...
} else if (ch === '\b' || ch === '\x7f') {
// backspace or ctrl+h
key.name = 'backspace';
key.meta = escaped;

It looks like the key modifier methods are just not checked for the backspace character, only the main keys (starting with [ or something).

Any idea why?

[SBoudrias]

@Fishrock123 the terminal option is defaulting to the isTTY check of the output stream. In this case, it looks like @dthree would already be in that mode no?

[jasnell]

ping @Fishrock123 ...
closing as there hasn't been any activity and doesn't look like an actionable issue

[dthree]

Meh. I'll do more research on it, and if I can get a better reproduction I'll file a more complete bug.

[fvydjt]

The bug is still there and I meet it today. When I use conhost or git bash or powershell(on Windows Terminal), the problem arises. But in VScode integrated terminal, this problem only appear when I use command prompt(conhost) and it doesn't occur when I use bash or powershell.