terminal: announce lower mouse tracking modes cumulatively - #1405
Open
kedimuzafer wants to merge 1 commit into
Open
terminal: announce lower mouse tracking modes cumulatively#1405kedimuzafer wants to merge 1 commit into
kedimuzafer wants to merge 1 commit into
Conversation
Mouse tracking modes 1000, 1002 and 1003 are separate flags in xterm, and applications set them cumulatively. mosh collapses them into a single mouse_reporting_mode value and announces only that one to the client terminal. When an application requests 1000h, 1002h and then 1003h, mosh forwards only 1003h. Terminals that do not implement 1003 ignore it and are left with no mouse reporting at all, even though they support 1000 and 1002 and would have worked over a plain ssh session. Announce the lower modes alongside the stored one so such terminals keep working. Fixes mobile-shell#1364 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #1364.
Mouse tracking modes 1000, 1002 and 1003 are separate flags in xterm, and applications set them cumulatively. mosh stores them in a single
mouse_reporting_modeand announces only the most recent one to the client terminal.Terminals need not implement every mode; the usual behaviour is to ignore an unsupported request and keep the mode already in effect. Because mosh forwards only the final mode, that fallback never happens — a terminal without 1003 ends up with mouse reporting entirely off, even though it supports 1000 and 1002.
Where we hit it
Android/Termux → mosh → tmux → a full-screen terminal application that requests
1000h 1002h 1003h 1006hat startup. Scrolling produced arrow keys instead of mouse events. Same phone, same server, same tmux over plain ssh: works.Measurements
Raw bytes read from the tty in Termux while scrolling, one mode at a time, no mosh in the path:
1000h1006h\e[<65;39;37M— SGR mouse1002h1006h\e[<64;35;28M— SGR mouse1003h1006h\e[A\e[B— arrow keysSo Termux implements 1000 and 1002 but not 1003. Then, same client and server, application sending all four modes:
1003hreaches the terminal, so nothing is enabledFix
Announce the lower modes alongside the stored one, mirroring what applications send. Terminals that do support 1003 are unaffected, since the higher mode takes precedence.
Scope
This is the minimal fix. #1364 also suggests recording every requested mode in order and replaying it, which would preserve exact ordering across arbitrary transitions; that is a larger change to the state model. The existing disable of the previous mode is left alone.
Testing
Built and run as the client on Android/Termux (aarch64) against an unpatched mosh 1.4.0 server: mouse reporting works again through mosh → tmux. Also builds clean on Linux x86_64. Behaviour unchanged on terminals that support 1003.
Credit to @Imberflur for diagnosing the root cause in #1364.