KiTTY icon indicating copy to clipboard operation
KiTTY copied to clipboard

[Bug] KITTY 0.76.0.2: Mouse scrolling in tmux does not work depending on how the session is started

Open Ivan1248 opened this issue 3 years ago • 9 comments
trafficstars

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:

  1. Set up mouse scrolling in tmux on the host by adding set -g mouse on to .tmux.conf, start tmux, overfill the vertical space with text inside tmux so that it can be scrolled (e.g. run seq 200) and close the SSH session.
  2. For both versions 0.76.0.1 and 0.76.0.2:
    1. Select the session and press "Open" in the "KITTY Configuration" window.
    2. Run tmux a in the host shell, and try to scroll inside tmux with the mouse.
    3. Observe that mouse scrolling works in both versions.
  3. For both versions 0.76.0.1 and 0.76.0.2:
    1. 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.
    2. Run tmux a in the host shell, and try to scroll inside tmux with the mouse.
    3. Observe that mouse scrolling works only in version 0.76.0.1.

Screenshots kitty-tmux-scrolling tmux-scrolling

Additional context sess.zip contains my session configuration from Computer\HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\Sessions\.

Ivan1248 avatar Nov 24 '21 17:11 Ivan1248

I can confirm that mouse scrolling in tmux doesn't work properly anymore. I went back to 0.74.4.13 for now.

Dubbeldrank avatar Dec 02 '21 12:12 Dubbeldrank

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.

systemmonkey42 avatar Dec 07 '21 10:12 systemmonkey42

not only tmux problem with scrolling. Only downgrade to 0.74.4.13 solved problem

romkazor avatar Dec 09 '21 14:12 romkazor

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.

Znuff avatar Jan 12 '22 15:01 Znuff

Hi all,

My observation is that:

  1. It only affects sessions started with KiTTY Configuration window.
  2. It DOES NOT affect sessions started with shortcuts, e.g. kitty.exe -load "my_session_1"
  3. It DOES NOT affect sessions started with JumpList (Recent Sessions).

Can anyone here confirm my findings please?

chrapuch avatar Feb 03 '22 08:02 chrapuch

Hi!

In my case, with KiTTY 0.76.0.2 (also 0.76.0.8), 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?

Ivan1248 avatar Feb 03 '22 13:02 Ivan1248

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

chrapuch avatar Feb 03 '22 15:02 chrapuch

I get the same result with 0.76.0.8.

Ivan1248 avatar Feb 03 '22 19:02 Ivan1248

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.

systemmonkey42 avatar Jul 02 '22 02:07 systemmonkey42

@cyd01 do you have any insight into this? This issue is 9 month old now, and you haven't weighed in.

systemmonkey42 avatar Aug 12 '22 23:08 systemmonkey42

I can solve a similar issue by changing the settings of the active window: Change Settings -> Category -> Window -> Appearance -> Apply.

alexxis avatar Aug 14 '22 10:08 alexxis

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.

systemmonkey42 avatar Sep 10 '22 03:09 systemmonkey42

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 avatar Sep 10 '22 04:09 Znuff

@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.

systemmonkey42 avatar Sep 10 '22 05:09 systemmonkey42

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.

I'll merge your fix and make a 0.76.0.11 release.

cyd01 avatar Sep 10 '22 08:09 cyd01

Thank you! It works.

Ivan1248 avatar Sep 12 '22 19:09 Ivan1248