[Bug]: Cannot reliably select/highlight text in chat messages #1144

Activity

1. samanthamsong

   added

   P2Normal priority bug or improvement with limited blast radius.Normal priority bug or improvement with limited blast radius.

   impact:ux-frictionUser-facing flow adds avoidable confusion or support burden without fully blocking progress.User-facing flow adds avoidable confusion or support burden without fully blocking progress.

   on Aug 10, 2026
2. clawsweeper

   added

   clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.

   clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.

   issue-rating: 🦪 silver shellfishThin issue quality; more reproduction proof or environment detail is needed.Thin issue quality; more reproduction proof or environment detail is needed.

   on Aug 10, 2026
3. clawsweeper commented on Aug 10, 2026

   

   clawsweeperbot

   on Aug 10, 2026 – with ClawSweeper

   Last edited by clawsweeper

   More actions

   Codex review: this still needs some work. Reviewed October 3, 2026, 4:38 PM ET / 20:38 UTC.

   Summary
   Keep open: no verified fix covers the reported interaction, and collaborator-authored issues require maintainer handling. Recent corroboration supports continued investigation, but the affected renderer remains unconfirmed.

   Reproducibility: no. high-confidence current-main reproduction is established. The report supplies clear drag steps, but the affected renderer/build is unconfirmed and related still images cannot show cursor tracking.

   Next step
   Retain maintainer ownership; confirm the app build, Gateway version, and chat setting, then capture the drag failure before selecting a repair path.

   Review details

   Best possible solution:

   Provide stable multiline selection within a message on the affected renderer while preserving whole-message Copy and accessibility.

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

   No high-confidence current-main reproduction is established. The report supplies clear drag steps, but the affected renderer/build is unconfirmed and related still images cannot show cursor tracking.

   Is this the best way to solve the issue?

   Unclear until the affected surface is identified. A focused repair to that renderer is preferable to reviving the retired renderer or treating whole-message Copy as a selection fix.

   AGENTS.md: found and applied where relevant.

   Remaining risk / open question:

   • The affected app build, Gateway version, and native-versus-WebView2 setting are not confirmed, so a renderer-specific repair cannot yet be bounded.

   Codex review notes: model internal, reasoning medium; reviewed against 7127c16d537c.

   Label changes

   Label changes:

   • remove clawsweeper:no-new-fix-pr: Current issue advisory state no longer selects this label.
   • remove clawsweeper:needs-maintainer-review: Current issue advisory state no longer selects this label.

   Label justifications:

   • P2: Selective copying is impaired, but the report does not establish a blocked core workflow.
   • impact:ux-friction: Unreliable highlighting makes extracting a chosen portion of a chat response cumbersome.

   Evidence reviewed

   What I checked:

   • Current renderer selection: ChatPage chooses WebView2 or Reactor from UseLegacyWebChat; SettingsData defaults that setting to false. The report explicitly names WebView2, so native-selection changes cannot establish that its behavior is fixed. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:270, 7127c16d537c)
   • Active native rendering boundary: Assistant text enters BuildSafeMarkdown, which directly invokes Microsoft.UI.Reactor.Factories.Markdown. The older in-repository ChatMarkdownRenderer is not this production entrypoint. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatTimeline.cs:602, 7127c16d537c)
   • Existing test and recovery scope: Native layout coverage asserts that an assistant RichTextBlock enables selection, but does not exercise multiline pointer dragging. The assistant footer also offers whole-message Copy, which does not resolve selective copying. (tests/OpenClaw.Tray.UITests/ReactorChatLayoutProofTests.cs:139, 7127c16d537c)
   • Earlier selection work: Merged improve(chat): make prose and simple lists one selectable text block #997 (improve(chat): make prose and simple lists one selectable text block) implemented continuous prose/list selection through the former FunctionalUI renderer. Its implementation and proof cannot establish current Reactor or WebView2 behavior. Merged Fix user chat bubble text rendering #883 (Fix user chat bubble text rendering) repaired user-bubble rendering rather than assistant drag selection. (4518dd87ed2b)
   • Recent related visual evidence: Both prepared screenshots from Copying chat contents in companion app is janky #1550 were inspected locally. Companion shows highlighting confined to one displayed block; the web dashboard comparison shows a broader selection. Still images support the reported friction but do not demonstrate pointer tracking or identify this issue's app build and renderer.
   • Corroborating discussion boundary: The September 26 commenter reports the same issue and links [Bug]: Cannot select multiple lines of text in OpenClaw Desktop Windows responses openclaw#158731 (comment). That comment routes the Windows application report to this repository; its closure does not establish a Windows chat fix.

   Likely related people:

   • bkudiess: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
   • karkarl: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
   • shanselman: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

   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.
4. github-actions commented on Sep 21, 2026

   

   github-actionsbot

   on Sep 21, 2026 – with GitHub Actions

   Contributor

   More actions

   This issue has been automatically marked as stale due to inactivity.
   Please add updated OpenClaw Windows details or it will be closed.
5. github-actions

   added

   stale

   on Sep 21, 2026
6. alexandre-leng commented on Sep 26, 2026

   

   alexandre-leng

   on Sep 26, 2026

   More actions

   openclaw/openclaw#158731 (comment) i have the same issue
7. github-actions

   removed

   stale

   on Sep 27, 2026
8. clawsweeper

   removed

   clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.ClawSweeper does not recommend queueing a new automated fix PR for this issue.

   clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.ClawSweeper marked this issue as needing maintainer review before automation.

   on Oct 3, 2026
9. clawsweeper commented on Oct 4, 2026

   

   clawsweeperbot

   on Oct 4, 2026 – with ClawSweeper

   Last edited by clawsweeper

   More actions

   🦞⚠️
   Automatic implementation stopped before completion.
   Reason: The automatic implementation worker stopped before all deterministic gates completed. Open the workflow run for the exact blocker.
   Worker: https://github.com/openclaw/clawsweeper/actions/runs/37173284595