Skip to content

Gibberish text and symbols #4601

Closed
Closed

Description

@itsJoKr

I think this is might be issue with recent update.

You can see everything in the provided image. It happens in both terminal and Claude, so it's definitelly Superset issue.

Opening a new window or resizing will fix this for some time.

Image

Activity

  1. saddlepaddle commented on May 15, 2026

    @saddlepaddle
    Collaborator

    Hi there, apologies this is high priority for us! We'll look into it immediately 👍🏼

  2. github-actions commented on May 15, 2026

    @github-actions
    Contributor

    Took a look at this — based on the description ("gibberish text and symbols" in both the terminal and Claude views, fixed temporarily by resizing or reopening the window), this looks like an xterm.js WebGL/canvas font-atlas state corruption: a refresh re-measures glyphs and gets the renderer back in sync.

    Relevant code I reviewed:

    • apps/desktop/src/renderer/screens/main/components/WorkspaceView/ContentView/TabsContent/Terminal/helpers.ts — WebGL addon load + onContextLoss handler that disposes and calls xterm.refresh(...). It does not set suggestedRendererType = "dom" after a context loss, so a later terminal will retry WebGL and hit the same path.
    • apps/desktop/src/renderer/lib/terminal/terminal-addons.ts — same WebGL pattern for runtime-managed terminals.
    • apps/desktop/src/renderer/lib/terminal/appearance/index.ts — font sanitization. The module-level monospaceCheckCache caches results from ctx.measureText; if a custom monospace font hasn't finished loading at first check time, the canvas measures with the proportional fallback and the (incorrect) "not monospace" result is cached for the lifetime of the renderer.

    I couldn't write a reproduction test because:

    1. The symptom is a GPU/canvas rendering glitch — bun:test runs in Node with a minimal DOM stub, no real canvas/WebGL, so the failure mode isn't observable.
    2. The trigger is timing- and environment-dependent (font loading, GPU context state, DPR changes), which I can't drive deterministically without a real Electron + browser harness.
    3. The screenshot wasn't enough to narrow it to a specific glyph-substitution pattern (e.g. icon font vs. ligature vs. atlas tearing) without seeing the affected characters and the exact context.

    To move this forward, could you share:

    • OS + version (macOS 14? Windows 11? Linux distro/Wayland or X11?)
    • Display setup — external monitor, mixed-DPI, recent display change before it appeared?
    • Superset version (Help → About) and roughly when the last update happened.
    • DevTools console output when the glitch is visible (View → Toggle Developer Tools, or Cmd+Option+I) — any WebGL context-loss warnings or font-related errors would pin this down quickly.
    • If you can: a few seconds of screen recording, or a sample of the gibberish text copy-pasted (the copy buffer holds the real characters even when rendering is glitched — that would tell us if it's a font/glyph substitution or a renderer artifact).

    Most likely root cause is a WebGL context-loss path that isn't fully resetting the renderer. As a workaround in the meantime: closing the bad pane and opening a new one (you already noted this works) avoids it until a fix lands.

  3. komly commented on May 15, 2026

    @komly

    Same problem multiple times a day. Please fix. Only restart helps.

  4. javierjavier commented on May 15, 2026

    @javierjavier

    @komly per @itsJoKr resize also temporarily fixes

  5. itsJoKr commented on May 15, 2026

    @itsJoKr
    Author
  6. itsJoKr commented on May 16, 2026

    @itsJoKr
    Author

    Also found some people complaining in Claude subreddit, but what's more interesting that I had issue in terminal (and other guy with Cursor), so that leads me to believe it's not Claude-only issue.

  7. pgt2195 commented on May 16, 2026

    @pgt2195

    When this gibberish text and symbols problem happens to me, I just resize the windows, or even just the terminal panel size, and it fixes it. I think the resize is forcing the terminal to rerender the text properly. But it's true that the bug is happening a lot these days.

  8. jgreer013 commented on May 16, 2026

    @jgreer013
    Image

    Such a funny bug

  9. Kitenite commented on May 17, 2026

    @Kitenite
    Member

    it's unfortunately an xterm issue, same reports in vscode as well. we're trying to see if we can fix it upstream

  10. KirkPX commented on May 26, 2026

    @KirkPX

    Just want to add that this is pervasive on my end too — the garbled/illegible text shows up regularly across both the terminal and Claude Code, and a window resize / new window only clears it temporarily. Saw the note that it's an upstream xterm.js issue with the candidate fix in xtermjs/xterm.js#5883 — would love to check in and see how things are going on getting a fix shipped. Thanks for the work on this!

  11. AviPeltz commented on Jul 10, 2026

    @AviPeltz
    Collaborator

    I believe this was fixed let me know if you see this issue persisting

  12. VXNCXNX commented on Jul 11, 2026

    @VXNCXNX

    Issue not fixed, this is happening again.
    Still reproducible on Superset Desktop 1.14.3 on macOS.
    This installation includes @xterm/xterm 6.1.0-beta.220 and@xterm/addon-webgl 0.20.0-beta.219, so the atlas-merge fix from #4893 is present.

    Resizing the pane/window forces a repaint and restores the correct glyphs temporarily.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions