Workspace transfer reads xterm private state because addon-serialize drops mouse encoding

[nedtwigg]

Problem

When a Workspace moves between standalone windows, each terminal is rebuilt in the target from @xterm/addon-serialize output (serializeTransferTerminal in lib/src/lib/terminal-transfer.ts). The pinned addon (@xterm/addon-serialize 0.15.0-beta.301, with @xterm/xterm 6.1.0-beta.304) serializes the mouse tracking mode (?1000 / ?1002 / ?1003) but not the mouse encoding: SGR (CSI ? 1006 h) or SGR-pixels (CSI ? 1016 h).

Without it, a full-screen program that turned on SGR mouse reporting (vim, tmux, htop, …) arrives in the new window with xterm's default encoding. From then on its mouse reports are misparsed, and clicks past column 223 cannot be encoded at all.

Current workaround (#630)

serializeTransferTerminal reads xterm's private terminal._core.mouseStateService.activeEncoding and appends \x1b[?1006h or \x1b[?1016h after the serialized buffer. docs/specs/transport.md → "Transferring a Workspace" requires the encoding to survive the move, and lib/src/lib/terminal-transfer.test.ts pins it against real xterm parsing:

• preserves mouse tracking and encoding %i through real xterm parsing
• does not resurrect encoding after reset %j
• still transfers the buffer if private mouse state is unavailable

The weakness is the private field. If an xterm bump renames or moves mouseStateService / activeEncoding, the lookup returns nothing and the buffer transfers without the encoding. The round-trip tests would fail that bump rather than let it regress silently, but the code still reaches into xterm internals.

Proposed fix

1. Upstream: have addon-serialize emit the active mouse encoding alongside the tracking mode (xtermjs/xterm.js, addons/addon-serialize).
2. Bump the pinned @xterm/* betas, respecting the version lockstep in docs/specs/webgl-text.md.
3. Delete the private-state read in serializeTransferTerminal; keep the round-trip tests as the regression pin.

[dormouse-bot]

The plan holds, but the pinned xterm already exposes the encoding through a documented protocol, so the private read can go without waiting on upstream.

DECRQM answers both encodings today. requestMode in @xterm/xterm@6.1.0-beta.304 (src/common/InputHandler.ts) resolves ?1006 and ?1016 from the very activeEncoding that serializeTransferTerminal reaches for, and replies CSI ? 1006 ; 1 $y through onData. DECRQM is in xterm's published VT feature set (@vt: #Y CSI DECRQM), not an internal. The plumbing is already on the #630 branch: REPLAY_REPORT_CSI in lib/src/lib/terminal-report-filter.ts already matches …$y and writeReplay already sets isReplaying, so the reply gets dropped rather than injected into the PTY, and serializeTerminal is already async around terminal.write via flushTerminal — which is exactly where a probe would await. The trade is a four-line synchronous property read for an async round-trip, a temporary onData listener, and a row in docs/specs/terminal-escapes.md. Not obviously the better shape, but it is available now and it is public surface.

Step 1 is a public API addition, not an addon tweak. _serializeModes builds its preamble from terminal.modes alone, and IModes has no encoding member. Emitting the encoding means first adding one to the modes getter in src/browser/public/Terminal.ts — which already derives mouseTrackingMode from this._core.mouseStateService.activeProtocol, immediately beside the activeEncoding we want — plus the typings. That clears a higher bar upstream than a change confined to addon-serialize.

Step 2 needs no new plumbing. The Renovate xterm group matches @xterm/** by scope, so @xterm/addon-serialize joined it automatically when #630 added it, and scripts/xterm-lint.mjs's provenance check walks every @xterm/* pin against that workspace's core pin. The new addon is covered without an edit.

Step 3 waits on #630. lib/src/lib/terminal-transfer.ts is not on main yet — it arrives with the workspaces train, so the deletion has nothing to delete until that lands.

One detail in the workaround's favour while it stands: mouseStateService is a public readonly member of CoreTerminal, and 'SGR' / 'SGR_PIXELS' are the names MouseStateService registers, so the exposure is to an unpublished-but-not-underscored surface rather than a truly private field.

Happy to open the upstream issue at xtermjs/xterm.js if you want it filed.