Mouse codes wrongly sent as SGR coordinates instead of UTF-8 on top/left of terminal

[flashcode]

Issue description

When the terminal or an application sets mouse mode with UTF-8 coordinates, tmux sometimes send SGR coordinates while it's not supposed to (only with the wheel, not buttons).

This happens on top/left of the terminal, when the mouse is approximately between 0 and 5 pixels from the left of the terminal.

See this video inside WeeChat (same problem outside WeeChat):

weird.webm

And also the issue reported against WeeChat: weechat/weechat#1893

Steps to reproduce:

1. Run one of these terminals: terminator, xfce4-terminal, gnome-terminal
2. Run tmux
3. Enable mouse with UTF-8 coordinates: printf "\e[?1005h\e[?1000h"
4. Move mouse pointer to top left
5. Use wheel up/down

Current behavior:

Mouse codes are sometimes sent as SGR coordinates: 64;0;4M for wheel up and 65;0;4M for wheel down.

Expected behavior:

Mouse codes are always sent as UTF-8 coordinates everywhere, including when using wheel on top left, like a!# for wheel down.

Additional notes

Bug is reproduced with:

• Tmux + one of these terminals: terminator, xfce4-terminal, gnome-terminal

Bug is NOT reproduced:

• Outside of tmux or with screen
• Tmux + one of these terminals: xterm, urxvt, kitty.

As the bug appears only with some terminals and only with tmux, I'm not sure if the problem is actually in tmux only or in the terminals.

But as I can't reproduce the bug at all outside tmux, I think the problem comes at least partially from tmux.

Required information

• tmux version (tmux -V): tmux 3.3a
• Platform (uname -sp): Linux unknown (Debian unstable)
• $TERM inside and outside of tmux (echo $TERM): outside = xterm-256color, inside = tmux-256color
• Logs: I can not send as there are sensitive info inside.

[nicm]

Show logs please or email them to me privately.

[flashcode]

Here are the logs, made with Terminator.

tmux-client-12676.log
tmux-out-12678.log
tmux-server-12678.log

[nicm]

This one seems to be a problem, tmux does not map it to a mouse key:

1679133539.044030 /dev/pts/0: mouse input (SGR): \033[<65;0;3M

[nicm]

This is not a valid SGR mouse sequence. The column and row positions start at 1, so 0 is out of range.

This means tmux does not recognise this as a mouse sequence and treats it as individual key presses, which is why you see it appear at the shell.

[nicm]

It seems like this is a bug in VTE. But probably tmux should just discard sequences when we can recognise they should be an SGR mouse sequence but are in fact invalid, I'll look at doing this next week.

[nicm]

Try this please:
x.diff.txt

[flashcode]

Hi @nicm,

Thanks for the patch, I tested and it works.

But I'm not sure if that's the best solution to the issue: if I use the wheel on the left, no mouse code is generated, so the wheel does not work here.

Wouldn't it better to consider that if 0 is received, tmux considers it's 1, so that the wheel works everywhere?

[nicm]

I'm not sure I like that idea much. What do the VTE developers say about this bug?

[flashcode]

Yeah your fix in tmux could be enough if this is going to be fixed in VTE as well.

I didn't ping them about this problem for your info (I don't even know where to do this).

[nicm]

Looks like here https://wiki.gnome.org/Apps/Terminal/ReportingBugs#Where_you_should_report_the_bug_to

[yut23]

I tracked this down to a missing check in VTE and filed an issue and a patch: https://gitlab.gnome.org/GNOME/vte/-/issues/2621

[nicm]

Great, thanks!

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.