Skip to content

fix(web): load terminal webfont before first paint and invalidate WebGL atlas - #1770

Merged
chuks-qua merged 1 commit into
mainfrom
fix/terminal-webfont-load
Sep 27, 2026
Merged

chuks-qua merged 1 commit into
mainfrom
fix/terminal-webfont-load

Conversation

@chuks-qua

@chuks-qua chuks-qua commented Sep 27, 2026 •

Copy link
Copy Markdown
Contributor

What

Terminal mounts raced the JetBrains Mono webfont download. @font-face files fetch lazily on first use and xterm never observes font loading, so a terminal opened on a cold font cache rasterized fallback glyphs. On the WebGL renderer (browser clients) those glyphs were baked into the texture atlas and stayed wrong for the whole session; some users saw Courier New instead of JetBrains Mono.

init() now warms document.fonts.load() for the resolved font family in parallel with the xterm module imports and awaits it, capped at 500 ms, before term.open. A new watchWebfontSettle helper listens for loadingdone while the WebGL addon is live and calls clearTextureAtlas() plus a full refresh, which also covers lazily fetched unicode-range subsets. The listener is removed through the existing claimWebglSlot release path, so teardown and context-loss swaps stay clean. Font load failure or timeout never blocks the mount; the CSS fallback chain still applies.

Why

The bundled JetBrains Mono is the intended terminal default but never reliably reached the screen. Users on a cold cache, slower connections, or the WebGL renderer got a stuck fallback face while Electron (DOM renderer) self-healed, which made the bug look per-user.

UI Changes

Correct rendering is the existing JetBrains Mono terminal font; there is no visual change when the font was already loading in time. The reported failure mode is a terminal stuck in the browser monospace fallback (Courier New on Windows/Firefox). Before/after capture via the live-testing harness was not feasible: Playwright is not installed in this environment (install requires approval), and the Electron path does not exercise the affected WebGL renderer. Verified instead by typecheck, lint, the terminal test suite, and confirming the dev server serves the fontsource CSS and woff2 assets (HTTP 200).

Review Notes

  • Terminal suite: 171/172 pass. The one failure (TerminalView.search.test.tsx "addon failure recovery") fails identically on the unmodified file and is pre-existing.
  • document.fonts access is guarded for non-browser test environments.

View with [code]smith Autofix with [code]smith
Need help on this PR? Tag @codesmith-bot with what you need. Autofix is disabled.

…GL atlas

@font-face files fetch lazily on first use and xterm never observes font
loading, so a terminal mounted on a cold font cache rasterized fallback
glyphs. The WebGL renderer baked them into its texture atlas for the whole
session. Await the resolved font family (bounded) before term.open and
rebuild the atlas on every font loadingdone event while WebGL is live.
@chuks-qua
chuks-qua merged commit 9370eed into main Sep 27, 2026
6 checks passed
@chuks-qua
chuks-qua deleted the fix/terminal-webfont-load branch September 27, 2026 21:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant