CJK text tops clipped in chat after v2026.7.1

[w909421774]

Title

CJK text tops are clipped in chat after v2026.7.1 (regression of #636)

Environment

• OpenClaw Companion v2026.7.1 (build 4206611)
• Windows 11, display scaling 100% / 125% (both affected)
• Chinese UI font: Microsoft YaHei (font fallback)

Steps to reproduce

1. Update to v2026.7.1.
2. Open any chat thread that contains Chinese text.
3. Look at the tops of Chinese glyphs (e.g. 设置、分析、资源).

Expected

All CJK glyph tops are fully visible, as in earlier versions.

Actual

The top ~1-2px of Chinese characters is clipped in chat messages.
Latin/digits are NOT affected. Other UI areas are NOT affected —
only the chat message area.

Notes

This looks like a regression of #636 (closed as fixed by #997):
#997 merged each message into a single RichTextBlock, and the line
height appears to be calculated from the primary (Latin) font metrics.
CJK glyphs have a taller top bearing than Segoe UI, so they exceed the
clip region and get cut. The Reactor theme migration (#1084) may also
play a role. Zoom/scaling changes do not help.

Attachments

(Screenshot showing a chat message where Chinese tops are clipped,
with a side-by-side before/after if possible.)

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 12, 2026, 3:18 PM ET / 19:18 UTC.

Summary
Keep open for native Windows confirmation. Current v2026.7.1 still uses a Markdown-to-RichTextBlock chat path, but source alone cannot establish which rendering branch clips CJK fallback glyphs or prove the reported cause.

Reproducibility: yes. The report supplies direct current-release Windows steps with Microsoft YaHei at 100% and 125%, but this review did not independently run a native Windows build.

Maintainer decision needed

Question	Recommendation
Should a Windows maintainer first confirm the supplied CJK clipping in the current release and identify the affected renderer branch before a repair PR is opened?	Confirm and scope a repair: Reproduce with Microsoft YaHei at both reported scales, capture the active visual-tree control, and authorize a focused renderer fix with regression proof.

Why: Source identifies plausible paths but cannot establish native font-fallback metrics or isolate the affected control from this read-only Linux review host.

Next step
A current-release native Windows confirmation is needed to identify whether the plain-text or Markdown renderer clips fallback glyphs before implementation can be safely bounded.

Review details

Best possible solution:

Reproduce the supplied CJK text on native Windows at 100% and 125%, identify the actual control path, then add the narrow layout correction with a CJK visual or UI-thread regression test.

Do we have a high-confidence way to reproduce the issue?

Yes. The report supplies direct current-release Windows steps with Microsoft YaHei at 100% and 125%, but this review did not independently run a native Windows build.

Is this the best way to solve the issue?

Unclear. The RichTextBlock explanation is plausible, but current code has both plain TextBlock and Markdown RichTextBlock paths, so native confirmation should choose the repair boundary first.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A hard-coded line-height change before identifying the active control could change wrapping and selection layout without fixing the reported font-fallback behavior.

Codex review notes: model internal, reasoning high; reviewed against 4206611f2b2e.

Label changes

Label justifications:

• P2: The current-release report describes a contained but visible chat-rendering regression without data loss, security, or availability impact.
• impact:ux-friction: Clipped CJK message text makes a core chat surface harder to read, while the report does not establish a complete workflow block.

Evidence reviewed

What I checked:

• Active assistant rendering path: Current main sends assistant text through SafeMarkdownText. Plain prose uses TextBlock, while block Markdown delegates to the Markdown renderer. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs:125, 4206611f2b2e)
• Relevant rich-text branch: Merged Markdown blocks create a selectable RichTextBlock without an explicit line height; FunctionalUI clears the property when no modifier supplies one. This identifies a candidate path but does not prove clipping. (src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs:321, 4206611f2b2e)
• Feature provenance: The merged selection feature touched both central renderer files and identifies Karen, GitHub login karkarl, as author. (src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs:54, 4518dd87ed2b)
• Release check: The checked-out current main is exactly the reporter's v2026.7.1 release, so there is no later main fix supporting closure. (4206611f2b2e)

Likely related people:

• karkarl: Merged PR 997 introduced the RichTextBlock coalescing path now used for Markdown assistant messages; its connection to this CJK report is plausible but not yet causal. (role: introduced the related chat selection renderer; confidence: medium; commits: 4518dd87ed2b, ff1901275a41; files: src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.

[w909421774]