Mouse events reporting toggle

[jamestut]

xterm.js currently always send mouse events (especially wheel and drag/selection) to the application if the application requested it. xterm.js have the option to force selection, such as the macOptionClickForcesSelection option. However, it would be great to disable the mouse events reporting entirely as some us find it annoying.

My primary use-case here is when I'm connecting using mosh: since mosh uses the alt buffer, scrolling on the xterm.js window will send those events to mosh, and mosh reinterpret these mouse events to the shell as up/down arrows, thus potentially undoing the commands that I've (partially) typed if I accidentally scrolled on the xterm.js window.

I have a patch working and will make a pull request soon.

[jerch]

To my knowledge there is no setting in xterm or gnome terminal to disable mouse tracking. Disabling mouse tracking on TE side unconditionally may break app side, if it expects mouse tracking to work. For these reasons I am not a big fan of disabling those.

The issue with mosh you mentioned sounds more like we should implement alternateScroll in DECSET (1007), so app side can customize scroll behavior.

NB: The PR you created stops the moue tracking at the event listeners, which is subpar. This is better done at level of registering mouse procotols (e.g. in InputHandler).

[Tyriar]

I agree with @jerch, if alternateScroll is what would make mosh behave nicer (or give it the option to at least) that would be the right way to go. Reasons:

• The proposed setting is yet another setting which I think we can avoid by behaving correctly
• A setting that changes these event handlers complicates the code
• alternateScroll seems like it's easier to implement as well

[jamestut]

Sorry for the delayed reply. So consider that most of the time I don't want my scroll to affect the state of terminal apps at all. Some of the reasons:

• I use trackpad a lot and sometimes a 3/4 finger gesture might trigger 2 finger gesture (scrolling) if my other fingers are not in contact enough).
• xterm.js is built-in VSCode. VSCode allows us to open both terminal and documents side-by-side. Sometimes in a split second I thought the terminal is a document, and scrolling on it would eradicate what I've typed on mosh (as mentioned before).

Disabling mouse tracking on TE side unconditionally may break app side, if it expects mouse tracking to work.

Hmm actually this is the exact behaviour that I wanted. Some apps expect mouse to be working, but I don't want to use it (primarily because it is unintuitive/slow, especially the primary reason I ran those apps is to "hide latency" and/or keeping my session running when connected on trans-atlantic servers and/or unstable cellular connection). The are not limited to mosh, sometimes it is tmux, screen, etc. And since many of my target are embedded servers, the tmux version might be of older version whose mouse behaviour can be quite different from others.

NB: The PR you created stops the moue tracking at the event listeners, which is subpar. This is better done at level of registering mouse procotols (e.g. in InputHandler).

Thank you for the suggestion! I'll have another look at it when I got the time and update the PR.

Also by the way, many terminal apps such as macOS' built-in Terminal.app and iTerm2 provides an option to disable mouse reporting entirely. Still, xterm.js is integrated to VSCode and this singlehandedly made this terminal app very convenient. It would be very awesome to have this option here. 🙏

[Tyriar]

@jamestut did you mean this setting?