feat(ui): add ctrl +/-/0 shortcuts for terminal font size

[geovannewashington]

What

While a terminal is focused, Ctrl + and Ctrl - step the terminal font size by one within the existing 8-24 range, and Ctrl 0 returns it to the default. Cmd substitutes for Ctrl on macOS. The keystroke is withheld from both the browser and the remote shell, so the page no longer zooms and no stray character lands on the command line.

Closes: #6936

Why

Changing the font size previously meant opening the settings drawer and clicking its +/- buttons, which is a mouse round-trip in the middle of a keyboard-driven task. Every native terminal binds these keys for this, so the muscle memory was already there but did nothing useful: the browser claimed the keystroke and zoomed the whole console UI instead of the terminal text.

The shortcut deliberately reuses the size that already exists rather than introducing a second one, so the drawer and the keyboard can never disagree and the choice keeps surviving reloads for free.

Changes

• New fontSizeShortcut.ts: a pure nextFontSize(current, event) that maps a keystroke to the size it asks for, or null. Keeping the step arithmetic behind this seam is what makes the whole behaviour unit-testable without constructing xterm.
• TerminalInstance.tsx: registers the handler via xterm's attachCustomKeyEventHandler, which is the seam that can withhold a key from the remote shell. It guards on keydown (the handler also fires for keyup), calls preventDefault() to suppress browser zoom, and reads the current size from the store rather than a render-time binding, since the handler is registered once and would otherwise always step from the size the terminal was created with.
• terminalThemeStore.ts: bounds and default extracted into exported constants now that a third caller needs them. Restoring a persisted size now parses defensively.
• TerminalSettingsDrawer.tsx: consumes those constants instead of repeating 8 and 24.

Two incidental fixes fell out of testing the store: a corrupt localStorage value was accepted as NaN and became the font size, and a persisted out-of-range value was applied unclamped.

Ctrl _ is deliberately not bound. - needs no Shift, so accepting it would buy nothing and would steal 0x1F (readline/emacs undo) from the remote shell.

Testing

Unit tests cover the two seams the behaviour actually lives at - 36 tests across nextFontSize and the store. The mapping is table-driven over +, =, -, 0, numpad, both modifiers, no modifier, Alt held, and unrelated keys.

These do not prove the feature works, only that the logic is right. Rendering xterm under jsdom was rejected (it needs a real canvas), so the wiring and the resize round-trip were exercised by hand in the running stack:

1. Open a web terminal and ssh root@dev.agent@localhost
2. Ctrl - / Ctrl + - terminal text resizes, console chrome (sidebar, tabs, taskbar) does not, confirming browser zoom is suppressed
3. No - or + character appears on the command line, confirming the key is withheld from the shell
4. Run htop, resize, and confirm it redraws correctly rather than corrupting - this is what proves the resize frame reached the PTY and the remote program got its SIGWINCH
5. Ctrl 0 snaps back to the default
6. Open the settings drawer and confirm it shows the keyboard-set size, then reload and confirm it persists

Known limitation

Holding the key is not as fluid as a native terminal. Each step reflows the scrollback, resizes the remote PTY and writes a recorder event, and that cost is per-step. An accelerating step was tried and reverted - it traded the slowness for visible jumpiness, which felt worse. Making it genuinely smooth needs a profile to establish which reflow dominates, so it is left alone here rather than tuned blind.

[otavio]

/review

[github-actions]

Code Review Complete

The automated review ran but did not post an updated summary — this usually means no new issues were found since the previous review. If you've pushed changes and want a fresh pass, comment /review.

View job