KiTTY
KiTTY copied to clipboard
[Bug] KITTY 0.76.0.2: Mouse scrolling in tmux does not work depending on how the session is started
Describe the bug Mouse scrolling in tmux and other programs does not work depending on how the session is started. This happens in version 0.76.0.2. In version 0.76.0.1 everything works fine.
It only works when the session is started by clicking on the "Open" button but not when started by clicking on the "Start" button or by running kitty -load <session_name>.
To Reproduce Steps to reproduce the behavior:
- Set up mouse scrolling in tmux on the host by adding
set -g mouse onto.tmux.conf, start tmux, overfill the vertical space with text inside tmux so that it can be scrolled (e.g. runseq 200) and close the SSH session. - For both versions 0.76.0.1 and 0.76.0.2:
- Select the session and press "Open" in the "KITTY Configuration" window.
- Run
tmux ain the host shell, and try to scroll inside tmux with the mouse. - Observe that mouse scrolling works in both versions.
- For both versions 0.76.0.1 and 0.76.0.2:
- Run
kitty -load <session_name>or- select a session and press "Start" in the "KITTY Configuration" window or
- select a session, press "Load" and press "Open" in the "KITTY Configuration" window.
- Run
tmux ain the host shell, and try to scroll inside tmux with the mouse. - Observe that mouse scrolling works only in version 0.76.0.1.
- Run
Screenshots

Additional context
sess.zip contains my session configuration from Computer\HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\Sessions\.
I can confirm that mouse scrolling in tmux doesn't work properly anymore. I went back to 0.74.4.13 for now.
I can also confirm. I am using tmux, with the mouse configured to scroll either the content (as in, the application like VIM) or the pane history/scrollback.
With the previous version, scrolling was handled by the running application (ie, TMUX or VIM). With the latest release, scrolling ONLY scrolls the kitty window, and is never sent to the running application.
To be specific - kitty.exe -load "session" - no mouse scrolling. kitty.exe - then select and load session from gui - mouse scrolling works.
not only tmux problem with scrolling. Only downgrade to 0.74.4.13 solved problem
I'm also experiencing a related (?) issue with this, I believe.
I use byobu on all my terminals (with a tmux backend), and ever since the upgrade from 0.74.x to 0.76.x, my mouse changes cursor style from a "text cursor" to a "mouse pointer" in tmux when running different stuff inside.
This breaks double-click selecting and it changes my copy/paste behavior.
This even persists when detaching from tmux.
I tried changing term type from xterm-256color (which I've been using for years as my default) to putty-256color or simply putty. Sadly, this most of the time fixes it, but it breaks other things (actual colors in the terminal, blue becomes green, and other weirdness). Now I'm saying "most of the time" because even with a TERM type of putty, I just had a new server installed that still exhibits the same issue even with that terminal.
I've tried using PuTTY 0.76.6 and I can not reproduce the issue at all with it. Obviously, this does not happen with KiTTY 0.74.x either.
It's been driving me crazy for 2 days since I updated.
Hi all,
My observation is that:
- It only affects sessions started with KiTTY Configuration window.
- It DOES NOT affect sessions started with shortcuts, e.g.
kitty.exe -load "my_session_1" - It DOES NOT affect sessions started with JumpList (Recent Sessions).
Can anyone here confirm my findings please?
Hi!
In my case, with KiTTY 0.76.0.2 (also 0.76.0.8), the bug affects:
- sessions started with the "Start" button in the KiTTY Configuration window,
- sessions started with
kitty.exe -load "my_session_1"through the command line or a shortcut, - sessions started by clicking on an item in the recent session list when right-clicking the KiTTY icon in the taskbar.
The bug DOES NOT affect sessions started with the "Open" button in the KiTTY Configuration window.
@chrapuch Which version do you use?
Hi!
In my case with KiTTY 0.76.0.2, the bug affects:
1. sessions started with the Start button in the KiTTY Configuration window, 2. sessions started with `kitty.exe -load "my_session_1"` through the command line or a shortcut, 3. sessions started by clicking on an item in the recent session list when right-clicking the KiTTY icon in the taskbar.The bug DOES NOT affect sessions started with the "Open" button in the KiTTY Configuration window.
@chrapuch Which version do you use?
0.76.0.6
I get the same result with 0.76.0.8.
I this issue being actively looked at? Its still a problem with 0.76.0.8 (I can't run any later builds because there are too many issues)
The fact it behaves differently between a connection via the dialog, and a connection via the command prompt should make it easier to track down.
@cyd01 do you have any insight into this? This issue is 9 month old now, and you haven't weighed in.
I can solve a similar issue by changing the settings of the active window: Change Settings -> Category -> Window -> Appearance -> Apply.
Hey,
I had a little free time, and I found the bug..
diff --git 0.76_My_PuTTY/terminal.c 0.76_My_PuTTY/terminal.c
index 471492e..74f359a 100644
--- 0.76_My_PuTTY/terminal.c
+++ 0.76_My_PuTTY/terminal.c
@@ -3042,7 +3042,11 @@ static void insch(Terminal *term, int n)
static void term_update_raw_mouse_mode(Terminal *term)
{
+#ifdef MOD_PERSO
+ bool want_raw = (term->xterm_mouse_mode && !term->xterm_mouse_forbidden);
+#else
bool want_raw = (term->xterm_mouse != 0 && !term->xterm_mouse_forbidden);
+#endif
win_set_raw_mouse_mode(term->win, want_raw);
term->win_pointer_shape_pending = true;
term->win_pointer_shape_raw = want_raw;
After the merge with putty, the differentiation between xterm_mouse and xterm_mouse_mode was lost.
For what it's worth, I had to recently upgrade (because I needed new cipher support for default Ubuntu 22.04 installs), and 0.76.0.10 doesn't seem to be exhibiting the mouse issue.
Been using it for almost 2 weeks now.
@Znuff Good for you.
As has been mentioned many times, the bug can be triggered or worked around in different ways. maybe you are using it in a specific way which avoids the bug.
There are TWO places where the mouse mode is checked. One is
void term_mouse(Terminal *term, Mouse_Button braw, Mouse_Button bcooked,
Mouse_Action a, int x, int y, bool shift, bool ctrl, bool alt)
{
pos selpoint;
termline *ldata;
#ifdef MOD_PERSO
bool raw_mouse = (term->xterm_mouse_mode &&
#else
bool raw_mouse = (term->xterm_mouse &&
#endif
!term->no_mouse_rep &&
!(term->mouse_override && shift));
int default_seltype;
and one is
static void term_update_raw_mouse_mode(Terminal *term)
{
bool want_raw = (term->xterm_mouse != 0 && !term->xterm_mouse_forbidden);
win_set_raw_mouse_mode(term->win, want_raw);
term->win_pointer_shape_pending = true;
term->win_pointer_shape_raw = want_raw;
term_schedule_update(term);
}
Since MOD_PERSO is a default build option (disabling it would remove most of kitty's extensions) it's pretty clear that in one case term->xterm_mouse_mode is checked, and in another case term->xterm_mouse is checked.
The second check (using xterm_mouse) is new as of the 0.76 putty merge, and appears to the source of the randomness in the behaviour.
Hey,
I had a little free time, and I found the bug..
diff --git 0.76_My_PuTTY/terminal.c 0.76_My_PuTTY/terminal.c index 471492e..74f359a 100644 --- 0.76_My_PuTTY/terminal.c +++ 0.76_My_PuTTY/terminal.c @@ -3042,7 +3042,11 @@ static void insch(Terminal *term, int n) static void term_update_raw_mouse_mode(Terminal *term) { +#ifdef MOD_PERSO + bool want_raw = (term->xterm_mouse_mode && !term->xterm_mouse_forbidden); +#else bool want_raw = (term->xterm_mouse != 0 && !term->xterm_mouse_forbidden); +#endif win_set_raw_mouse_mode(term->win, want_raw); term->win_pointer_shape_pending = true; term->win_pointer_shape_raw = want_raw;After the merge with putty, the differentiation between
xterm_mouseandxterm_mouse_modewas lost.
I'll merge your fix and make a 0.76.0.11 release.
Thank you! It works.