Dashboard: Chat output invisible until enough content generated (rendering/layout bug)

[anathusic]

Bug Report

Hermes Version: v0.17.0 (2026.6.19) · upstream 44d552e
OS: macOS
Browser: Dashboard (web UI)

Description

In the web dashboard, new chat messages and assistant responses are not visible after being generated. The content appears to be rendered off-screen or outside the visible viewport. Only after a sufficient amount of output has been generated does the content accidentally scroll into view.

Steps to Reproduce

1. Open the Hermes web dashboard
2. Send a message and wait for the assistant response
3. The response is generated (streaming completes) but remains invisible (appears as black/blank area)
4. Only after generating a large enough amount of content does the output suddenly become visible

Expected Behavior

New assistant messages should be immediately visible after being rendered. The chat should auto-scroll to the latest message.

Actual Behavior

• Output is generated but invisible in the viewport
• Manual scrolling does not help — the content is not just off-screen, it seems to be mispositioned or overlapping incorrectly
• The content only becomes visible by chance once enough messages accumulate to push it into the correct render area

Possible Cause

Likely a CSS layout / positioning bug — potentially related to:

• Incorrect , , or on the chat container
• Auto-scroll not working, combined with initial content being rendered above the visible area
• Theme: configured (though changing theme did not resolve the issue)

Additional Context

• The issue is consistently reproducible in the web dashboard
• Telegram and Terminal interfaces work correctly without this issue
• Workaround: Use Telegram instead of the web dashboard

[alt-glitch]

This was generated by AI during triage.

Duplicate of #48363 — same symptom: web dashboard chat content renders invisible/off-screen (CLI and Telegram unaffected), a dashboard CSS layout/auto-scroll bug. Consolidating there.

[kypkk]

I'd like to help fix this. The dashboard chat is an xterm.js terminal (not a DOM chat log), so this looks like a renderer/fit timing bug: the WebGL addon loads after term.open() + first fit(), and ws.onmessage writes never scrollToBottom() — so early rows paint into a stale atlas and stay black until a scroll forces a redraw. Plan: force term.refresh() + scrollToBottom() after WebGL loads and on first PTY output, guard the initial fit against a zero-height host, and pin auto-scroll on write.

[anathusic]

Workaround

Typing /redraw in the dashboard chat forces a full re-render and makes all previously invisible content visible immediately.

Useful until the underlying xterm.js WebGL/Atlas bug is fixed.

[anathusic]

Additional finding: Mobile view

On mobile browsers, the /redraw workaround does not work. The only option is to switch to desktop view, which has its own layout issues and is not a good experience on mobile.

Summary of workarounds by platform:

• Desktop browser: /redraw fixes the invisible content
• Mobile browser: no working workaround — switching to desktop view is the only option but layout is broken there too

[anathusic]

Additional finding: Tablet

On tablet browsers, /redraw also does not work — same as mobile. The chat remains black until enough output is generated to trigger a re-render naturally.

So the /redraw workaround only works on desktop browsers.