When the vt200 mouse mode is enabled, touch scrolling emits wheel events with a very high frequency. I suspect this happens because
|
if ((ev as WheelEvent).deltaY !== 0) { |
|
action = (ev as WheelEvent).deltaY < 0 ? CoreMouseAction.UP : CoreMouseAction.DOWN; |
|
} |
only checks that
deltaY !== 0, instead of summing multiple
deltaYs until the sum is greater than some threshold.
The real-world consequence of this is that tmux mouse-scrolling (well, touchpad scrolling) is basically unusable because the sensitivity is way too high.
Details
- Browser and browser version: Electron 17.4.1/Chromium 98/VS Code 1.67
- OS version: Manjaro
- xterm.js version: Whatever is shipped in VS Code, but also doesn't really matter
Steps to reproduce
printf "\e[?1000h" in an xterm.js terminal and a more native terminal (I was using alacritty, the original report was about whatever terminal is the default on Macs)- Use a touchpad to scroll
- Check the frequency of the emitted scroll events
Or just start tmux and enable mouse mode via set -g mouse on; you should notice a difference in scroll speed between the two terminals.
When the vt200 mouse mode is enabled, touch scrolling emits wheel events with a very high frequency. I suspect this happens because
xterm.js/src/browser/Terminal.ts
Lines 707 to 709 in a5f2ea3
only checks that
deltaY !== 0, instead of summing multipledeltaYs until the sum is greater than some threshold.The real-world consequence of this is that tmux mouse-scrolling (well, touchpad scrolling) is basically unusable because the sensitivity is way too high.
Details
Steps to reproduce
printf "\e[?1000h"in an xterm.js terminal and a more native terminal (I was using alacritty, the original report was about whatever terminal is the default on Macs)Or just start
tmuxand enable mouse mode viaset -g mouse on; you should notice a difference in scroll speed between the two terminals.