fix(desktop): prevent .xterm from inheriting Tailwind's sans-serif stack (#3570)

[allenxln]

What this does

Adds a font-family: ui-monospace, monospace declaration to the existing .xterm rule in apps/desktop/src/renderer/globals.css, so the terminal element's computed font-family stops inheriting Tailwind preflight's sans-serif stack.

Why

While investigating #3570 (corrupted glyphs in CJK locales on macOS), getComputedStyle(document.querySelector('.xterm')).fontFamily returned:

ui-sans-serif, system-ui, sans-serif, "Apple Color Emoji", ...

— no monospace family at all. Meanwhile terminal.options.fontFamily (set in terminal-runtime.ts:109 from appearance/index.ts:42) is a monospace stack starting with JetBrains Mono.

Tracing the CSS:

• @xterm/xterm@6.0.0/css/xterm.css never sets font-family on .xterm itself (only on .xterm-accessibility-tree), by design — xterm expects the renderer's options.fontFamily to drive glyph rendering.
• The repo's existing .xterm rule in apps/desktop/src/renderer/globals.css only sets height/width.
• So .xterm inherits from body, which uses Tailwind v4 preflight's default ui-sans-serif, system-ui, sans-serif, ... stack.

When xterm's internal CSS-based measurement paths (DOM measure fallback, ligatures addon shaping via getComputedStyle) run against that proportional stack while the WebGL renderer rasterizes glyphs from the monospace stack, the texture atlas gets written with metrics that don't match the cell grid — the exact "distorted, overlapping glyph fragments" shown in the issue.

Two reported workarounds (DevTools open, window resize) both trigger xterm resize → atlas rebuild at a point when the initial font-loading / CSS race has settled, which is consistent with this hypothesis.

Scope

Intentionally minimal (single declaration). A more complete fix would make .xterm's DOM font-family track terminal.options.fontFamily exactly (e.g. by injecting the stack as a CSS variable from terminal-runtime.ts), so a user-customized terminal font is also reflected in the DOM. Happy to follow up with that once the direction is confirmed.

Related

• [Bug] Latin/ASCII characters render as corrupted glyphs when mixed with Chinese text #3570 — the issue this addresses
• fix(desktop): force WebGL repaint on load and fall back to DOM after context loss #3477 — complementary: forces atlas repaint after addon load

Testing

I haven't set up a local desktop build to validate end-to-end, and I'm keeping this as Draft partly for that reason. A few honest notes on why I think that's an acceptable state for this particular change:

• The reasoning above is derived entirely from checked-in source (xterm.css, globals.css, terminal-runtime.ts, appearance/index.ts) plus repro data captured from a running install, so the premise is verifiable without a build.
• The change is a single CSS declaration inside an existing @layer base rule — very small blast radius, and straightforward to review or revert.
• Terminal-rendering issues of this class are hard to cover reliably in unit tests (the existing issue thread notes the same), and the visual effect depends on OS locale + font set + Electron + xterm WebGL runtime interacting — not something a fresh environment on my side would likely reproduce as cleanly as an already-affected user's machine.

That said, happy to do whatever local setup is expected — just flag it. Reviewers with a running build and a CJK-locale macOS should be able to verify by:

1. Inspecting .xterm's computed font-family before and after this change.
2. Checking whether the garbled-glyph state still appears on fresh startup.

---

Summary by cubic

Add font-family: ui-monospace, monospace to the .xterm rule so the terminal stops inheriting Tailwind’s sans-serif stack. This prevents WebGL atlas corruption and garbled glyphs on startup (notably in CJK locales on macOS) and fixes #3570.

^{Written for commit 4692449. Summary will update on new commits.}

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: fad53807-9bed-4357-b11d-fee80f718fc4

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[allenxln]

Gentle nudge — happy to keep waiting, but wanted to leave one breadcrumb in case it helps prioritize:

#3554 (fix(desktop): recover terminal from non-monospace font crash) addressed the case where the xterm runtime ends up with a proportional font. This PR is arguably a closely related "silent" variant of the same class: the .xterm element's computed font-family inherits Tailwind's sans stack even when terminal.options.fontFamily is correctly set to a monospace stack, so xterm's CSS-driven measurement paths and the WebGL glyph rasterizer disagree on metrics — which presents as the garbled atlas reported in #3570 rather than an outright crash.

No rush on merging; just flagging the connection in case it shortens the review context. Still happy to follow up with a broader fix (propagating terminal.options.fontFamily into a CSS variable so user-customized fonts also reach the DOM) once direction is confirmed.