Mouse reporting doesn't work

[Gskartwii]

Describe the bug

Terminal applications that make use of mouse reporting don't react to mouse events at all.

Environment (please complete the following information):

• OS: Host is Windows 10, running WSL (version 2, Ubuntu 20.04) invoked by running wsl from cmd.exe inside Wezterm.
• Version: wezterm 20200620-160318-e00b076c
• (Wezterm was installed from Scoop.)

To Reproduce

1. Start Wezterm.
2. Run wsl to enter a WSL prompt.
3. $ sudo apt install vttest
4. Run vttest.
5. Choose 11: non-VT100 terminals
6. Choose 8: XTERM special features
7. Choose 5: Mouse features
8. Choose 1 twice to choose SGR coordinates (the same behaviour is seen regardless of the mode, though).
9. Choose 4 to test "normal mouse tracking".
10. Try clicking the terminal or moving the mouse. vttest doesn't output anything.

Alternatively: run vim, then type :set mouse=a, insert some text and try to select the text. Vim remains in normal mode.

Configuration

No user configuration used (I renamed %USERPROFILE%\.config\wezterm\wezterm.lua to .lua.bak to test this).

Expected behavior

I expected vttest to indicate that it was receiving mouse tracking events by outputting something. In the Vim reproduction, I expected Vim to enter the "select" or "visual" mode.

Screenshots

N/A

Session Recording

N/A; the issue is with input as far as I can tell.

Additional context

I remember mouse events working previously with a very similar setup, but they have been broken since I reinstalled Windows a few days ago. Unfortunately, I already deleted my old installation files, so I have no way to check my configuration. The trouble is that this makes voidmap nearly unusable, and that application is pretty important to me.

[wez]

Mouse reporting on Windows relies on using the openconsole.exe and conpty.dll that we ship because microsoft/terminal#376 has not been resolved in Windows itself yet.

Those need to be deployed in the same directory as wezterm.exe to work.

I don't know if the Scoop installation flow does this correctly, and I'd recommend that you try installing using the setup.exe based installer from the download page to rule that out.

[Gskartwii]

Thanks for the reply. I just uninstalled the version from Scoop and installed the latest one from the GitHub releases (WezTerm-20200620-160318-e00b076c-setup.exe). However, the behaviour appears to be the same.

I also tried using a command from a Stack Exchange answer to check if mouse events were being transmitted:

[wez]

I don't have wsl2 available locally so I can't test exactly your environment. However, mouse reporting does work for me in vim under wsl; that's how I do my wezterm development on windows! One other difference from the scenario you described is that I tend to use the launcher menu (right click the + in the tab bar) to launch into wsl; the launcher menu should show a list of the WSL distributions installed. I'm not sure if that works with WSL 2 (I'd appreciate your feedback on that!).

The mouse reporting test you shared shows that mouse reports are coming through to wsl2, although 1015 is urxvt mode which wezterm doesn't support because of its ambiguous encoding. I'd suggest using echo -e "\e[?1000;1003;1006h" to turn on motion and click tracking with sgr encoding. You can use echo -e "\e[?1000;1003;1006l" to turn it off again (h is for setting those modes high (on) and l is for low (off)).

[Gskartwii]

Starting WSL2 from the launcher menu seems to work just fine. Thanks for the tip!

Having done that, I tried echo -e "\e[?1000;1003;1006h"; xxd. With that command, nothing happens when I click the terminal or hover the mouse over it.

[wez]

It's definitely working for me with both the latest release and the latest nightly. So... I wonder why not for you?

In the task manager, if you expand the WezTerm app, do you see OpenConsole.exe as a child process?

[Gskartwii]

No, OpenConsole isn't running:

Here's also the view from Process Explorer, in case that helps:

[wez]

I updated openconsole.exe; I don't know if that will help here, but it's been a while since the prior build was baked and bundled.
Maybe it will help?
It's also possible that this is somehow specific to wsl2, which I'm unable to test.

[Gskartwii]

Sorry about the hassle! It turns out simply rebooting Windows was enough to fix this (which would've usually been the first thing I try, if it weren't for the HDD erasing that I didn't want to interrupt). OpenConsole.exe is now running, and mouse events work just fine. Thanks for your support.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.