---
** [tickets:#128] Do not send scroll-wheel release events to clients.**
**Status:** open
**Created:** Thu May 08, 2014 06:31 AM UTC by Timothy Allen
**Last Updated:** Thu May 08, 2014 06:31 AM UTC
**Owner:** nobody
xterm and other terminal emulators (like modern gnome-terminal) just send a
single scroll-wheel event ("button 64 pressed" for scroll up, "button 65
pressed" for scroll down) when the user scrolls their mousewheel. Some
terminals (including older versions of gnome-terminal, and PuTTY 0.63) also
immediately send a corresponding button-release event, which is incorrect but
an understandable mistake.
In the classic xterm mouse-reporting mode, every button sends the same escape
sequence when released, so they're typically ignored and the bogus
scroll-release events cause no harm. However, in the modern SGR mouse-reporting
protocol button-release events have a distinct, natural encoding which can
confuse clients that aren't expecting them.
For example, when tmux is running inside PuTTY, it asks PuTTY for SGR
mouse-reporting. If a client asks tmux in turn for SGR mouse-reporting, tmux
reports incoming mouse events faithfully, even the bogus ones, but if the
client asks for classic xterm mouse-reporting, tmux sends corrupt, impossible
escape sequences (where a classic mouse-release event sets the button field to
0x23, tmux adds the 'mouse-wheel button' flag, setting the button field to
0x63).
It seems to me that if the containing terminal sends obviously bad input to
tmux, tmux shouldn't pass that on to the client running inside, and it
definitely shouldn't corrupt things further. Therefore, if tmux receives an
SGR-formatted button-release event for buttons 64 or 65, it should just discard
them entirely.
---
Sent from sourceforge.net because tmux-users@lists.sourceforge.net is
subscribed to https://sourceforge.net/p/tmux/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/tmux/admin/tickets/options. Or, if this is a mailing
list, you can unsubscribe from the mailing list.------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
tmux-users mailing list
tmux-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tmux-users
