openclaw - ✅(Solved) Fix [Bug]:Dashboard Chat page freezes browser — infinite "Loading chat…" on v2026.3.8 and v2026.3.11-beta.1 [1 pull requests, 2 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#43857Fetched 2026-04-08 00:18:33
View on GitHub
Comments
2
Participants
2
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
commented ×2labeled ×2cross-referenced ×1

The Dashboard Chat page freezes the browser tab completely after navigating to it. The page shows "Loading chat…" and then becomes unresponsive ("This page is not responding").

The Overview page works perfectly — only the Chat page is affected.

Error Message

Gateway logs show no errors — all requests are served successfully. The issue is entirely client-side.

Root Cause

The Dashboard Chat page freezes the browser tab completely after navigating to it. The page shows "Loading chat…" and then becomes unresponsive ("This page is not responding").

The Overview page works perfectly — only the Chat page is affected.

Fix Action

Fixed

PR fix notes

PR #46707: fix(ui): replace marked.js with markdown-it to fix ReDoS UI freeze [AI-assisted]

Description (problem / solution / changelog)

Summary

  • Replace marked.js (regex-based) with markdown-it (state machine) to eliminate ReDoS vulnerability that caused permanent UI freeze on nested JSONL session transcripts
  • Preserve all custom rendering behaviors: HTML escaping, base64-only images, code block copy buttons, JSON auto-collapse
  • Add ReDoS regression test with desensitized real session pattern

Fixes #45283

Likely same root cause:

  • #43857
  • #44107

AI-assisted

This PR was developed with Claude Opus 4.6. Fully tested (958 test files, 8066 tests passed). The contributor understands all changes.

Test plan

  • pnpm build passes
  • pnpm check passes
  • pnpm test — 958 test files, 8066 tests passed
  • ReDoS regression test: markdown-it renders poison pattern in <500ms (marked.js hangs indefinitely)
  • All existing markdown tests pass unchanged (basic rendering, XSS prevention, code blocks, tables, image handling, cache, error fallback)

🤖 Generated with Claude Code

Changed files

  • pnpm-lock.yaml (modified, +11/-10)
  • ui/package.json (modified, +2/-1)
  • ui/src/markdown-it-task-lists.d.ts (added, +10/-0)
  • ui/src/styles/chat/text.css (modified, +14/-0)
  • ui/src/ui/markdown.test.ts (modified, +426/-6)
  • ui/src/ui/markdown.ts (modified, +283/-75)

Code Example

## Logs

Gateway logs show no errors — all requests are served successfully. The issue is entirely client-side.
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Summary

Description

The Dashboard Chat page freezes the browser tab completely after navigating to it. The page shows "Loading chat…" and then becomes unresponsive ("This page is not responding").

The Overview page works perfectly — only the Chat page is affected.

Steps to reproduce

Environment

  • OpenClaw: 2026.3.11-beta.1 (b125c3b)
  • OS: macOS 15.6.1 (Sequoia, Build 24G90)
  • Node.js: v24.13.0
  • Browser: Microsoft Edge 145.0.3800.97 (also reproduced via Playwright Chromium)
  • Gateway auth mode: token
  • Gateway bind: loopback (127.0.0.1:18789)

Steps to Reproduce

  1. Start OpenClaw gateway (openclaw gateway or via launchd)
  2. Open Dashboard Overview page → works fine, shows version and health status "正常"
  3. Click "Chat" in the sidebar (or navigate directly to /chat)
  4. Page shows "Loading chat…" then freezes — browser reports "This page is not responding"

Investigation Results

Backend is healthy — this is a pure frontend rendering issue:

  • All API endpoints respond normally (50-80ms):
    • GET /api/v1/chat.history → 200 OK
    • GET /api/v1/node.list → 200 OK
    • GET /api/v1/device.pair.list → 200 OK
  • WebSocket connections succeed (confirmed in gateway.log)
  • HTTP responses for /chat return 200 with valid HTML
  • Control UI static assets exist and load correctly

Frontend analysis:

  • The SPA uses Lit-based Web Components (<openclaw-app>)
  • The A$() function (line ~5571 in index-_Qfb-veq.js) renders the chat thread
  • When e.loading is true, it displays "Loading chat…"
  • The rendering of chat history messages via T$() with rd() keyed repeat appears to block the main thread
  • Chat history data loads fine from the API, but DOM rendering causes the freeze

What I've tried (none resolved it):

  • Upgraded from v2026.3.8 → v2026.3.11-beta.1 (same behavior)
  • Cleared browser cache
  • Tested in multiple browsers (Edge + Playwright Chromium)
  • Restarted gateway multiple times
  • Verified all backend APIs are responsive

Expected behavior

Expected Behavior

Chat page should load and display the chat interface without freezing the browser.

Actual behavior

Actual Behavior

Chat page freezes the entire browser tab after showing "Loading chat…". The browser's process becomes unresponsive and requires force-closing the tab.

Logs

Gateway logs show no errors — all requests are served successfully. The issue is entirely client-side.

OpenClaw version

2026.3.11-beta.1 (b125c3b)

Operating system

macOS 15.6.1 (Sequoia, Build 24G90)

Install method

No response

Model

claude opus 4.6

Provider / routing chain

github-copilot/claude-sonnet-4.6

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

## Logs

Gateway logs show no errors — all requests are served successfully. The issue is entirely client-side.

Impact and severity

No response

Additional information

No response

extent analysis

Problem Summary

The Chat page freezes because the Lit component that renders the chat history creates thousands of DOM nodes in a single synchronous loop (T$() / rd() repeat). The browser spends all its time building the huge tree, so the UI becomes “not responding”.

Root Cause

  • Recent UI change added a full‑history repeat without pagination or virtualization.
  • Rendering all messages at once blocks the main thread.
  • The backend is fine; the issue is purely client‑side rendering.

Fix Plan

1. Add pagination / limit to the data sent to the UI

// src/api/chat.ts
export async function fetchChatHistory(page = 1, pageSize = 200) {
  const resp = await fetch(`/api/v1/chat.history?page=${page}&size=${pageSize}`);
  const { messages, total } = await resp.json();
  return { messages, total, page, pageSize };
}
  • Update the gateway (if needed) to accept page/size query parameters and return a slice of the history.
  • Keep the existing endpoint for backward compatibility.

2. Render only a window of messages with lit‑virtualizer

  1. Install the package (once):
    npm i @lit-labs/virtualizer
  2. Update the Chat component (e.g. chat-page.ts):
import { LitElement, html, css } from 'lit';
import { repeat } from 'lit/directives/repeat.js';
import { virtualize } from '@lit-labs/virtualizer';

export class ChatPage extends LitElement {
  static properties = {
    messages: { type: Array },
    total: { type: Number },
    loading: { type: Boolean },
    page: { type: Number },
    pageSize: { type: Number },
  };

  constructor() {
    super();
    this.messages = [];
    this.total =

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING