VT/xterm mouse reporting not working at all outside of WSL

[jhmaster2000]

Windows Terminal version

1.17.11461.0

Windows build number

Microsoft Windows [Version 10.0.19045.3448]

Other Software

PowerShell 7.4.0-preview.5
WSL version: 1.2.5.0

Steps to reproduce

To reproduce the expected behavior inside WSL: echo -e '\E[?1006h' + echo -e '\E[?1003h'

To reproduce the faulty behavior outside WSL: Write-Output "$([char]27)[?1006h" + Write-Output "$([char]27)[?1003h"

Extra info

According to #545 (comment), #14958, this article and lots of other sources everything seems to indicate this is supposed to be supported, even outside of WSL according to the last article.

I've already found references of some comments saying "QuickEdit" mode might interfere with VT mouse capture, but I already turned that off and it still doesn't work. I've also already tried the command: Set-ItemProperty HKCU:\Console VirtualTerminalLevel -Type DWORD 1 but I'm pretty sure that was already set anyway.

I can also reproduce this outside of WT with pwsh.exe directly, and have looked through the PowerShell repository issues for this too, but found conflicting cases of people being redirected back and forth between that repository and this one for similar issues to mine (because apparently conhost issues are also tracked here?), so I'm not really sure which one this would fit better, feel free to move the issue to PowerShell if I guessed wrong.

Expected Behavior

Inside WSL, I obtain the following:

jhmaster@Ubuntu:~$ echo -e '\E[?1006h'

jhmaster@Ubuntu:~$ echo -e '\E[?1003h'

jhmaster@Ubuntu:~$ 35;66;17m35;65;17m35;64;17m35;64;16m35;63;16m35;62;16m35;61;16m...

from moving the mouse around after the two inputs. I expected the same feedback outside of WSL.

Actual Behavior

Outside of WSL:

PS C:\...> Write-Output "$([char]27)[?1006h"

PS C:\...> Write-Output "$([char]27)[?1003h"

PS C:\...>

No matter what is done with the mouse, move, drag, click, scroll, etc no feedback is given by the terminal.

[lhecker]

You cannot use the existence of visible output in the shell as an indication whether mouse mode is enabled or not.

When mouse mode is enabled, the terminal writes these sequences (\e[35;66;17m, etc.) to the shell / terminal application which then reads them via stdin. Whether the shell then writes this input to stdout is up to the shell. When you say "WSL" for instance, what you actually see is bash writing the stdin input to stdout. Other shells under WSL like zsh or fish don't do that. PowerShell under Windows doesn't do it either.

Do you have an application that runs outside of WSL where mouse mode doesn't work? You could try writing your own test application in C or C# for instance.

[jhmaster2000]

@lhecker Ah I didn't know that, thanks for the info. My intent there was to try to do a reproduction as close to the shells themselves as possible to cut out any possible middleman like a runtime, but I suppose I shot myself in the foot instead, oops.

In that case I did originally run into this with a small test Node.js script:

// @file vt.mjs
const
    PRESSED_LMB = 0b00_0_000_00, // 0       [MB1]
    PRESSED_MMB = 0b00_0_000_01, // 1       [MB2]
    PRESSED_RMB = 0b00_0_000_10, // 2       [MB3]
    PRESSED_NONE = 0b00_0_000_11, // 3 (1+2)
    MODIF_SHIFT = 0b00_0_001_00, // 4
    MODIF_META = 0b00_0_010_00, // 8
    MODIF_CTRL = 0b00_0_100_00, // 16
    MOTION_EVENT = 0b00_1_000_00, // 32
    FLAG_MB4_7 = 0b01_0_000_00, // 64
    SCROLL_UP = 0b01_0_000_00, // 64        [MB4]
    SCROLL_DOWN = 0b01_0_000_01, // 65 (64+1) [MB5]
    USED_MB6 = 0b01_0_000_10, // 66 (64+2) [MB6]
    USED_MB7 = 0b01_0_000_11, // 67 (64+3) [MB7]
    FLAG_MB8_11 = 0b10_0_000_00, // 128
    USED_MB8 = 0b10_0_000_00, // 128         [MB8]
    USED_MB9 = 0b10_0_000_01, // 129 (128+1) [MB9]
    USED_MB10 = 0b10_0_000_10, // 130 (128+2) [MB10]
    USED_MB11 = 0b10_0_000_11, // 131 (128+3) [MB11]
    __$stub__ = null;
const BUTTON_STATE_PRESSED = 'M';
const BUTTON_STATE_RELEASED = 'm';

process.stdin.resume();
process.stdin.setRawMode(true);
//process.stdout.write('\x1B[?2004h'); // Enable bracketed paste mode
process.stdout.write('\x1B[?1006h'); // Enable SGR mouse mode
process.stdout.write('\x1B[?1003h'); // Enable any event mouse mode
// 1000 -> only listen to button press and release
// 1002 -> listen to button press and release + mouse motion only while pressing button
// 1003 -> listen to button press and release + mouse motion at all times

process.on('exit', () => {
    // disable all the modes
    //process.stdout.write('\x1B[?2004l');
    process.stdout.write('\x1B[?1006l');
    process.stdout.write('\x1B[?1003l');
});
process.stdin.on('data', (buf) => {
    const seq = buf.toString('utf8');
    if (seq === '\u0003') {
        console.error('Ctrl+C');
        return process.stdin.pause();
    }
    if (!seq.startsWith('\x1B[<')) return; // not a mouse event
    const [btn, x, y] = seq.slice(3, -1).split(';').map(Number);
    const event = {};
    if (btn & FLAG_MB8_11) {
        if ((btn & USED_MB11) === USED_MB11) event.button = 'MB11';
        else if ((btn & USED_MB10) === USED_MB10) event.button = 'MB10';
        else if ((btn & USED_MB9) === USED_MB9) event.button = 'MB9';
        else event.button = 'MB8';
    }
    else if (btn & FLAG_MB4_7) {
        if ((btn & USED_MB7) === USED_MB7) event.button = 'MB7';
        else if ((btn & USED_MB6) === USED_MB6) event.button = 'MB6';
        else if ((btn & SCROLL_DOWN) === SCROLL_DOWN) event.button = 'scroll_down';
        else event.button = 'scroll_up';
    }
    else {
        if ((btn & PRESSED_NONE) === PRESSED_NONE) event.button = null;
        else if (btn & PRESSED_RMB) event.button = 'right';
        else if (btn & PRESSED_MMB) event.button = 'middle';
        else event.button = 'left';
    }
    event.state = seq.at(-1) === BUTTON_STATE_PRESSED ? 'pressed' : 'released';
    event.x = x;
    event.y = y;
    event.motion = !!(btn & MOTION_EVENT);
    event.shift = !!(btn & MODIF_SHIFT);
    event.meta = !!(btn & MODIF_META);
    event.ctrl = !!(btn & MODIF_CTRL);
    logMouseEvent(event);
});
const $ = {
    bold: '\x1B[1m',
    dim: '\x1B[2m',
    underline: '\x1B[4m',
    blink: '\x1B[5m',
    invert: '\x1B[7m',
    invisible: '\x1B[8m',
    reset: '\x1B[0m',
    //noBold: '\x1B[21m', (broken)
    noDim: '\x1B[22m',
    noUnderline: '\x1B[24m',
    noBlink: '\x1B[25m',
    noInvert: '\x1B[27m',
    visible: '\x1B[28m',
    black: '\x1B[30m',
    red: '\x1B[31m',
    green: '\x1B[32m',
    yellow: '\x1B[33m',
    blue: '\x1B[34m',
    purple: '\x1B[35m',
    cyan: '\x1B[36m',
    white: '\x1B[37m',
    gray: '\x1B[90m',
    redBright: '\x1B[91m',
    greenBright: '\x1B[92m',
    yellowBright: '\x1B[93m',
    blueBright: '\x1B[94m',
    purpleBright: '\x1B[95m',
    cyanBright: '\x1B[96m',
    whiteBright: '\x1B[97m',
};
console.log($.gray + 'Listening to mouse events:' + $.reset);
function logMouseEvent(event) {
    const { button, state, x, y, motion, shift, meta, ctrl } = event;
    console.log(
        `${(state[0] === 'r' ? $.green : $.red) + upperFirst(state).padEnd(8) + $.reset} ` +
        `${(button ? '' : $.dim) + (button ?? 'none').padEnd(11) + $.reset} at ${$.gray}(` +
        `${$.reset + $.yellow}${x.toString().padStart(3)}${$.reset + $.gray}, ` +
        `${$.reset + $.yellow}${y.toString().padStart(3)}${$.reset + $.gray})${$.reset} ` +
        `${motion ? $.purple : $.dim}[MOTION]${$.reset} ${shift ? $.blue : $.dim}[SHIFT]${$.reset} ` +
        `${meta ? $.cyan : $.dim}[META]${$.reset} ${ctrl ? $.yellow : $.dim}[CTRL]${$.reset}`
    );
}
function upperFirst(str) { return str[0].toUpperCase() + str.slice(1); }

Ran with Node.js v20.2.0 as: node vt.mjs (please note the .mjs extension is important if trying to repro) on both sides (inside WSL and out)

And here's an example of expected output from the script:

PS C:\...> wsl node ./js/vt.mjs
Listening to mouse events:
Released none        at (  1,  14) [MOTION] [SHIFT] [META] [CTRL]
Released none        at (  2,  14) [MOTION] [SHIFT] [META] [CTRL]
Released none        at (  3,  14) [MOTION] [SHIFT] [META] [CTRL]
Released none        at (  4,  14) [MOTION] [SHIFT] [META] [CTRL]
Released none        at (  5,  14) [MOTION] [SHIFT] [META] [CTRL]
Released none        at (  6,  14) [MOTION] [SHIFT] [META] [CTRL]
Released none        at (  7,  14) [MOTION] [SHIFT] [META] [CTRL]
Pressed  left        at (  7,  14) [MOTION] [SHIFT] [META] [CTRL]
Released left        at (  7,  14) [MOTION] [SHIFT] [META] [CTRL]
Pressed  right       at (  7,  14) [MOTION] [SHIFT] [META] [CTRL]
Released right       at (  7,  14) [MOTION] [SHIFT] [META] [CTRL]
Pressed  left        at (  7,  14) [MOTION] [SHIFT] [META] [CTRL]
Released left        at (  7,  13) [MOTION] [SHIFT] [META] [CTRL]
Pressed  scroll_down at (  7,  12) [MOTION] [SHIFT] [META] [CTRL]
...

whereas without wsl only the first line Listening to mouse events: gets printed and no further feedback.

Edit:
Additionally in the JS source I also tried adding an unconditional console.log('seq:', seq); before the if (!seq.startsWith('\x1B[<')) return; // not a mouse event check, incase it was some encoding issue that caused that check to fail or something of the sort, but negative, truly nothing is being sent from mouse actions. (But from that new log I do can see keyboard presses being received, so its also not Node.js on Windows that is failing to receive TTY events or something like that either)

[lhecker]

My intent there was to try to do a reproduction as close to the shells themselves as possible to cut out any possible middleman like a runtime

FYI The shell doesn't really sit in the middle between the terminal and the application it spawns. It's not like this:

flowchart TD
    Terminal --> Shell --> Application

Loading

but rather like this:

flowchart TD
    Terminal --> Shell
    Terminal --> Application

Loading

The "Shell" doesn't accidentally snatch away input from your "Application" simply because the shell waits for the application to exit before it continues reading from stdin.

Additionally in the JS source I also tried adding an unconditional console.log('seq:', seq); before the if (!seq.startsWith('\x1B[<')) return; // not a mouse event check, incase it was some encoding issue that caused that check to fail or something of the sort, but negative, truly nothing is being sent from mouse actions.

If you do it like that you won't see any output since seq will contain an escape sequence, which aren't visible text (the terminal parses them away). Try this instead:

console.log('seq: ', JSON.stringify(seq));

I currently don't have nodejs installed and haven't used it in a while. So if the above doesn't help you resolve the issue and if no one else comes along in the meantime, I might only come around to debug this in a little bit (after finishing up 1.19). 😥

[lhecker]

Oh right, I should've asked: Do you have node installed inside WSL? Because if you don't then wsl node will call the Windows node.exe through a compatibility shim (ConPTY) through WSL which goes through the shim again and back into Windows Terminal. If you do that, and if the above JSON.stringify didn't help resolve the issue, try installing node inside WSL. If that finally resolves the issue it's probably a bug in system ConPTY (which we maintain).

[jhmaster2000]

My intent there was to try to do a reproduction as close to the shells themselves as possible to cut out any possible middleman like a runtime

FYI The shell doesn't really sit in the middle between the terminal and the application it spawns. It's not like this:

flowchart TD
    Terminal --> Shell --> Application

Loading

but rather like this:

flowchart TD
    Terminal --> Shell
    Terminal --> Application

Loading

The "Shell" doesn't accidentally snatch away input from your "Application" simply because the shell waits for the application to exit before it continues reading from stdin.

Additionally in the JS source I also tried adding an unconditional console.log('seq:', seq); before the if (!seq.startsWith('\x1B[<')) return; // not a mouse event check, incase it was some encoding issue that caused that check to fail or something of the sort, but negative, truly nothing is being sent from mouse actions.

If you do it like that you won't see any output since seq will contain an escape sequence, which aren't visible text (the terminal parses them away). Try this instead:

console.log('seq: ', JSON.stringify(seq));

I currently don't have nodejs installed and haven't used it in a while. So if the above doesn't help you resolve the issue and if no one else comes along in the meantime, I might only come around to debug this in a little bit (after finishing up 1.19). 😥

Holy bonkers, quick offtopic here but I didn't know GitHub had support for fancy flowcharts like that, that's amazing. Thanks for showing me those (and the info itself of course)

Anyway, you're right about the seq value itself not showing with that, I actually originally did it with console.dir(seq) which showed the string's inspected value properly, that was just a bit of a poor recreation, my bad. But even with that poor recreation you can still tell whether something is being sent at all or not because the 'seq:' string before the actual value would print :P (which I also tested it indeed doesn't)

Oh right, I should've asked: Do you have node installed inside WSL? Because if you don't then wsl node will call the Windows node.exe through a compatibility shim (ConPTY) through WSL which goes through the shim again and back into Windows Terminal. If you do that, and if the above JSON.stringify didn't help resolve the issue, try installing node inside WSL. If that finally resolves the issue it's probably a bug in system ConPTY (which we maintain).

Well oops again, I thought wsl <cmd> would just be a shortcut for wsl and then entering the command inside, which is just what I wanted to signal was happening in that snippet, I do have node installed inside WSL and get the same working-as-intended output from running node vt.mjs inside WSL manually instead of wsl <cmd>.