Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Code block leading whitespace trimmed by WebChat UI, breaking ASCII diagram alignment [2 pull requests, 1 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#81339•Fetched 2026-05-14 03:33:10
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
1
Author
Tonwee2022Tonwee2022
Participants
clawsweeper[bot]clawsweeper[bot]Tonwee2022Tonwee2022
Timeline (top)
cross-referenced ×2labeled ×2commented ×1

Leading whitespace in code blocks is stripped by WebChat UI input, breaking ASCII box-drawing alignment

Root Cause

The WebChat frontend appears to call .trim() or equivalent on the input string before submission, which removes all leading and trailing whitespace characters including:

  • Regular spaces (U+0020)
  • Fullwidth spaces (U+3000 　)
  • Possibly all Unicode whitespace

Only zero-width spaces (U+200B ​) survive because they are not classified as whitespace characters — but they are invisible and have zero width, making them unusable as visual alignment aids.

Fix Action

Fix / Workaround

The issue is particularly painful because:

  1. The user cannot see the problem until the message is sent (what-you-see in the input box ≠ what you get)
  2. The fix requires either workarounds (adding a visible placeholder character at each line start) or editing after posting, adding friction to every diagram-heavy conversation

PR fix notes

PR #81344: fix(webchat): preserve leading message whitespace

Description (problem / solution / changelog)

Summary

  • Problem: WebChat trims composer text before optimistic display and chat.send, so pasted code blocks lose leading indentation and ASCII diagrams break.
  • What changed: keep the submitted message string intact through handleSendChat, queued sends, optimistic WebChat message rendering, and chat.send; use trimmed text only for blank-message guards and slash/stop/BTW command detection.
  • What did NOT change: server-side control-character sanitization, attachment handling, slash-command parsing semantics, or gateway transcript/history projection.

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Fixes #81339
  • This PR fixes a bug or regression

Root Cause (if applicable)

  • Root cause: handleSendChat() used (messageOverride ?? host.chatMessage).trim() as the submitted message, and sendChatMessage() trimmed again before optimistic display and RPC submission.
  • Missing guardrail: WebChat controller/host tests did not cover leading indentation in a multi-line user message.

Regression Test Plan (if applicable)

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target tests:
    • ui/src/ui/controllers/chat.test.ts: controller preserves the exact submitted text in optimistic display and chat.send payload.
    • ui/src/ui/app-chat.test.ts: host handleSendChat() preserves a multi-line indented draft through the WebChat send path.
  • Scenario the tests lock in: a pasted diagram containing leading spaces on continuation lines is submitted exactly as typed.
  • Why this is the smallest reliable guardrail: these are the two places that previously called .trim() on WebChat message content before submission.

User-visible / Behavior Changes

WebChat preserves leading whitespace in sent text, including code blocks and diagram lines. Whitespace-only messages are still rejected unless attachments are present.

Diagram (if applicable)

Before:
composer draft -> trim() -> optimistic message + chat.send -> leading columns lost

After:
composer draft -> blank/command checks use trim()
               -> optimistic message + chat.send use original text

Security Impact (required)

  • New permissions/capabilities? No
  • Secrets/tokens handling changed? No
  • New/changed network calls? No
  • Command/tool execution surface changed? No
  • Data access scope changed? No
  • If any Yes, explain risk + mitigation: N/A

Real behavior proof

  • Behavior or issue addressed: WebChat send path now preserves leading spaces in multi-line diagram text for both the optimistic user message and the chat.send payload.
  • Real environment tested: Local OpenClaw checkout on Linux with Node v22.22.0, executing the real ui/src/ui/controllers/chat.ts send path from this branch.
  • Exact steps or command run after this patch: Ran pnpm exec tsx against sendChatMessage() with a pasted multi-line diagram containing six leading spaces on continuation lines, capturing the actual chat.send request payload and optimistic message state.
  • Evidence after fix: Console output from the live command:
{
  "sentSecondLine": "      |               +-- R122 10K",
  "optimisticSecondLine": "      |               +-- R122 10K",
  "sentLeadingSpaces": 6,
  "optimisticLeadingSpaces": 6
}
  • Observed result after fix: The second diagram line retained six leading spaces in both surfaces that previously received trimmed text: the outgoing chat.send payload and the optimistic WebChat user message.
  • What was not tested: Full browser screenshot was not captured; the exercised path is the real WebChat controller path used by the browser host.

Repro + Verification

Environment

  • OS: Linux dev checkout
  • Runtime/container: local Node/pnpm repo checkout
  • Model/provider: N/A
  • Integration/channel: WebChat UI
  • Relevant config (redacted): N/A

Steps

  1. Submit a WebChat draft containing:
+5V --+-- R68 3.3K --+-- TP175
      |               +-- R122 10K
      +-- R122 10K --+-- TP128
  1. Inspect the optimistic WebChat user message.
  2. Inspect the chat.send RPC payload.

Expected

  • Continuation lines keep the six leading spaces.
  • chat.send receives the exact submitted text.
  • Whitespace-only messages without attachments still do not send.

Actual

  • Matches expected after this patch.

Evidence

  • Failing source path before + passing after
  • Console output from the real WebChat controller send path
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

  • Source proof before fix:
    • ui/src/ui/app-chat.ts used (messageOverride ?? host.chatMessage).trim() as the submitted message.
    • ui/src/ui/controllers/chat.ts used const msg = message.trim() before optimistic display and requestChatSend().
  • Automated proof after fix:
    • pnpm test ui/src/ui/controllers/chat.test.ts ui/src/ui/app-chat.test.ts
    • Result: 2 files passed, 102 tests passed.
  • The new regression tests assert the exact sent string and exact optimistic message text, including leading spaces on diagram continuation lines.

Next step before merge

Review the small UI send-path diff and let CI run.

Changed files

  • ui/src/ui/app-chat.test.ts (modified, +36/-0)
  • ui/src/ui/app-chat.ts (modified, +18/-17)
  • ui/src/ui/controllers/chat.test.ts (modified, +21/-0)
  • ui/src/ui/controllers/chat.ts (modified, +10/-7)

PR #81377: fix(ui): preserve leading whitespace in WebChat code blocks

Description (problem / solution / changelog)

Summary

WebChat UI was trimming both leading and trailing whitespace from user messages before submission, breaking ASCII diagram alignment in code blocks.

Changes

Changed trim() to trimEnd() in three locations in ui/src/ui/app-chat.ts:

  1. enqueueChatMessage() - preserves leading whitespace when queuing messages
  2. enqueuePendingRunMessage() - preserves leading whitespace for steered messages
  3. handleSendChat() - preserves leading whitespace when submitting

This preserves leading whitespace (critical for code block alignment) while still removing trailing whitespace.

Test Plan

Manually tested:

  1. Paste code block with leading spaces for box-drawing alignment
  2. Send message in WebChat
  3. Verify leading spaces are preserved

Before fix:

+5V ──┬── R68
│               ├── R122 10K   ← leading spaces stripped

After fix:

+5V ──┬── R68
      │               ├── R122 10K   ← leading spaces preserved

Security Considerations

  • Does not introduce new secrets handling: No
  • Changes authentication or authorization: No
  • Exposes new network endpoints: No
  • Changes exec behavior: No

Human Verification

  • Tested: Manual verification in local WebChat
  • Not tested: Automated tests (existing test coverage)

Fixes #81339

Changed files

  • ui/src/ui/app-chat.ts (modified, +3/-3)

Code Example

+5V ──┬── R68 3.3K ──┬── TP175 ──→ L/R SELECT
      │               ├── R122 10K
      │               └── Z3 → GND
      │
      └── R122 10K ──┬── TP128
                      └── Z3 → GND

---

+5V ──┬── R68 3.3K ──┬── TP175 ──→ L/R SELECT
│               ├── R122 10K
│               └── Z3 → GND
│
└── R122 10K ──┬── TP128
└── Z3 → GND

---

+5V ──┬── R68 3.3K ──┬── TP175 ──→ L/R SELECT
      │               ├── R122 10K
      │               └── Z3 → GND
      │
      └── R122 10K ──┬── TP128
                      └── Z3 → GND

---
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

Leading whitespace in code blocks is stripped by WebChat UI input, breaking ASCII box-drawing alignment

Steps to reproduce

① Open WebChat ② Paste a code block with indented box-drawing chars ③ Send ④ Observe leading spaces missing

Expected behavior

Code block content preserves all leading whitespace as typed

Actual behavior

All leading spaces (U+0020) and fullwidth spaces (U+3000) are trimmed before submission

OpenClaw version

v2026.5.7

Operating system

Windows 11

Install method

npx openclaw

Model

deepseekV4 Flash

Provider / routing chain

openclaw/deepseek/v4 flash

Additional provider/model setup details

Description

When pasting a code block containing ASCII/Unicode box-drawing diagrams (e.g., circuit schematics, tree structures, tables) into the OpenClaw WebChat input box, leading spaces before the box-drawing characters are silently stripped before the message is sent. This causes all indentation-based alignment to break, making any text-based diagram unreadable.

Since box-drawing characters (─, │, ┬, ├, └) rely on precise column alignment in monospace code blocks, the loss of leading whitespace at the start of each line destroys the entire diagram.

Reproduction Steps

  1. Open the OpenClaw WebChat interface
  2. Prepare a code block with leading spaces for alignment:
+5V ──┬── R68 3.3K ──┬── TP175 ──→ L/R SELECT
      │               ├── R122 10K
      │               └── Z3 → GND
      │
      └── R122 10K ──┬── TP128
                      └── Z3 → GND
  1. Paste it into the WebChat input box and send
  2. Observe that all leading spaces before the │, ├, └, ┌ characters are gone

Actual Behavior

+5V ──┬── R68 3.3K ──┬── TP175 ──→ L/R SELECT
│               ├── R122 10K
│               └── Z3 → GND
│
└── R122 10K ──┬── TP128
└── Z3 → GND

All indentation is lost. The diagram becomes unreadable.

Expected Behavior

The code block should appear exactly as typed, preserving all leading whitespace:

+5V ──┬── R68 3.3K ──┬── TP175 ──→ L/R SELECT
      │               ├── R122 10K
      │               └── Z3 → GND
      │
      └── R122 10K ──┬── TP128
                      └── Z3 → GND

Root Cause Analysis

The WebChat frontend appears to call .trim() or equivalent on the input string before submission, which removes all leading and trailing whitespace characters including:

  • Regular spaces (U+0020)
  • Fullwidth spaces (U+3000 　)
  • Possibly all Unicode whitespace

Only zero-width spaces (U+200B ​) survive because they are not classified as whitespace characters — but they are invisible and have zero width, making them unusable as visual alignment aids.

Scope of Impact

This affects any user who needs to write text-based diagrams in code blocks:

  • Circuit schematics using box-drawing characters (common in embedded/EE discussions)
  • ASCII art architecture diagrams
  • Tree structures (├──, └──)
  • Indented code samples where leading indentation is semantically meaningful (e.g., Python tracebacks)
  • Markdown table-like structures drawn with box-drawing characters
  • Any monospace/typewriter-style formatting relying on column alignment

The issue is particularly painful because:

  1. The user cannot see the problem until the message is sent (what-you-see in the input box ≠ what you get)
  2. The fix requires either workarounds (adding a visible placeholder character at each line start) or editing after posting, adding friction to every diagram-heavy conversation

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

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…

FAQ

Expected behavior

Code block content preserves all leading whitespace as typed

#request error#file not found#serialization error#model compatibility#GPU setup

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Code block leading whitespace trimmed by WebChat UI, breaking ASCII diagram alignment [2 pull requests, 1 comments, 2 participants]