Custom cross-control selection engine so the whole chat transcript is drag-selectable

[karkarl]

Problem

Chat messages render markdown into a FunctionalUI Element tree. Prose (paragraphs + headings) and now simple lists coalesce into a single per-message RichTextBlock so they are one continuous drag-selection scope (branch karkarl-chat-bubble-richtextblock, commit 47b335d, follow-up to 2fa7279). However, selection is still fragmented at every styled island:

• Code blocks, tables, block quotes, thematic breaks, and any complex list (an item containing one of those) render as their own controls and are their own selection islands.
• You cannot drag-select from one message into another, or across a code block, in one gesture.

This is a hard WinUI limitation, confirmed during the RichTextBlock work:

• InlineUIContainer breaks text selection at its boundary and is excluded from SelectedText, so styled cards cannot be embedded in-flow without losing selection.
• There is no built-in mechanism for continuous selection spanning multiple sibling controls.
• TextHighlighter keeps text in-flow and selectable but only hugs glyphs per line (no padding/border/rounded corners/scroll), so it cannot preserve code-card chrome.

The per-message Copy button is the current whole-message grab affordance, and simple lists + prose now select as one block — this issue tracks going the rest of the way.

Goal

Whole-transcript (or at least whole-message, spanning styled islands) continuous selection, while keeping code blocks / tables / block quotes as separately styled, chrome-bearing surfaces.

Approach (to design)

Build a custom selection manager plus a custom UI Automation ITextProvider / ITextRangeProvider over the chat surface so a single drag maps to a logical text range that crosses control boundaries:

• Hit-test + anchor/focus tracking across child controls (prose RichTextBlocks + island cards).
• A logical document/offset model that stitches the rendered blocks into one selectable stream (including code/table text).
• Custom TextPattern provider for accessibility + Ctrl+C semantics that mirror the visible selection.
• Painting the selection highlight across islands without the native per-control selection overlay fighting it.

Constraints

• Keep the inert-markdown security posture (no Hyperlink/BitmapImage; AppendInlines stays inert).
• Preserve the selection-preservation cache invariant (re-render/AST-reparse must not wipe an active selection).
• Keep code/table/blockquote visual chrome intact.

References

• Branch karkarl-chat-bubble-richtextblock, commits 2fa7279 (prose coalescing) and 47b335d (simple-list coalescing) — PR pending from this branch; cross-link once opened.
• File: src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs (coalescing + island rendering).

Out of scope

The RichTextBlock coalescing already landed. This issue is the larger custom-selection-engine follow-up.

[karkarl]

Base implementation landed in #997 (per-message RichTextBlock coalescing prose + simple lists). This issue tracks the custom cross-control selection engine to extend selection across the styled islands (code/table/blockquote) that #997 leaves separate.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 16, 2026, 12:06 AM ET / 04:06 UTC.

Summary
The requested capability remains missing: current main is the base of the still-open partial implementation at #997, which explicitly leaves styled islands and cross-message selection unresolved. This substantial native interaction and accessibility subsystem needs an explicit scope and ownership decision before implementation.

Likely related people: karkarl (high confidence, designed and implemented the adjacent RichTextBlock work), shanselman (medium confidence, native-app product routing), and ranjeshj (medium confidence, recent chat/tray work).

Reproducibility: not applicable. the fragmented selection scopes are an acknowledged native-control limitation, and this issue requests a new custom interaction model rather than reporting broken behavior against an existing contract.

Root-cause cluster
Relationship: canonical
Canonical: #995
Summary: This issue is the canonical remaining request for continuous selection across styled islands; the linked PR is a deliberate partial improvement and the Reactor migration is adjacent architecture work.

Members:

• partial_overlap: improve(chat): make prose and simple lists one selectable text block #997 - The PR coalesces prose and simple lists into a per-message selection scope but explicitly leaves styled islands and cross-message selection unresolved.
• adjacent_distinct: Port OpenClawTray.FunctionalUI to Reactor to stop hand-maintaining bespoke UI primitives #996 - Changing the declarative UI framework may affect implementation choices but does not itself provide logical cross-control selection, clipboard semantics, or a TextPattern provider.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Include the exact command, prompt, or workflow that triggered it.
• Add expected vs actual behavior.

Next step
A maintainer must first sponsor the permanent custom-selection contract and choose a per-message or transcript-wide boundary; this is not a safe autonomous fix-PR task.

Maintainer decision needed

• Question: Should the Windows native chat own a custom cross-control selection and UI Automation subsystem, and if so should its first supported boundary be one message or the entire transcript?
• Rationale: The approach is technically plausible but creates a permanent interaction, accessibility, rendering, and performance contract whose scope and maintenance cost require explicit product ownership.
• Likely owner: shanselman — The unresolved choice concerns native-app product scope and long-term ownership rather than a mechanical renderer repair.
• Options:
  • Prototype per-message selection (recommended): Sponsor a narrow spike crossing styled islands within one message and require keyboard, clipboard, UIA, rerender, scrolling, and visual proof before expansion.
  • Keep native controls: Retain native per-control selection plus the whole-message Copy affordance and avoid owning a parallel text-selection stack.
  • Build transcript-wide selection: Treat the logical transcript, multi-message selection, custom painting, and UIA provider as a larger planned native-chat initiative.

Review details

Best possible solution:

Resolve the bounded baseline in #997, then sponsor a per-message design spike with one logical-document owner and proof for pointer selection, keyboard and Ctrl+C behavior, UI Automation ranges, styled-island painting, scrolling, and rerender preservation before considering transcript-wide scope.

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

Not applicable: the fragmented selection scopes are an acknowledged native-control limitation, and this issue requests a new custom interaction model rather than reporting broken behavior against an existing contract.

Is this the best way to solve the issue?

Unclear as proposed: a custom logical selection and UIA layer is the direct technical route, but transcript-wide scope is not yet shown to be the narrowest maintainable solution; a per-message prototype should establish feasibility and ownership first.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Custom-painted selection could disagree with native focus, keyboard extension, clipboard ordering, scrolling, virtualization, or per-control selection overlays.
• A custom ITextProvider and ITextRangeProvider would become an accessibility contract that must stay synchronized with rendered markdown and selection state across rerenders.
• Transcript-wide scope could turn a bounded per-message enhancement into a large persistent subsystem with significant performance and ownership costs.

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

Label changes

Label changes:

• add P3: This is a speculative, high-complexity chat ergonomics feature with an existing copying fallback, not an urgent broken workflow.
• add impact:ux-friction: Users cannot drag-select continuously across styled chat islands or messages, making partial transcript copying less convenient without fully blocking copying.
• add issue-rating: 🌊 off-meta tidepool: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is a speculative, high-complexity chat ergonomics feature with an existing copying fallback, not an urgent broken workflow.
• impact:ux-friction: Users cannot drag-select continuously across styled chat islands or messages, making partial transcript copying less convenient without fully blocking copying.

Evidence reviewed

What I checked:

• Current-main boundary: The linked PR is based on current main SHA bf0fa8a and states that code blocks, tables, block quotes, thematic breaks, complex lists, and cross-message selection remain separate selection islands. (src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs, bf0fa8a9bde4)
• Partial implementation remains open: improve(chat): make prose and simple lists one selectable text block #997 implements only per-message coalescing for prose and simple lists and explicitly tracks this issue as the larger cross-control follow-up; it is not a substitute for the requested engine. (src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs, 47b335d25428)
• Concrete design constraints: The discussion records that native sibling controls do not share selection, InlineUIContainer breaks SelectedText, and TextHighlighter cannot preserve the required card chrome, leaving a new logical-range, painting, clipboard, and UI Automation design. (src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs, bf0fa8a9bde4)
• Repository UI review policy: AGENTS.md requires focused automated validation, current-head visible proof, and rubber-duck review for non-trivial chat UX changes; its architecture guidance also favors one narrow, tested ownership seam per PR. (AGENTS.md:277, bf0fa8a9bde4)
• Existing fallback limits urgency: The issue and linked PR preserve a per-message Copy button for whole-message copying, so fragmented drag-selection is meaningful UX friction but does not block chat or copying. (src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs, bf0fa8a9bde4)
• Release and main provenance: Latest release v0.6.12 predates this July 15, 2026 request, while the supplied current-main SHA is also the base of the open partial PR; neither provenance supports an implemented-on-main close. (4166e0fd63f8)

Likely related people:

• karkarl: Authored the detailed WinUI selection analysis and the adjacent RichTextBlock/coalescing commits that define the current selection-island boundary. (role: adjacent feature designer and contributor; confidence: high; commits: 2fa72790, 47b335d25428; files: src/OpenClaw.Tray.WinUI/Chat/Markdown/ChatMarkdownRenderer.cs, src/OpenClawTray.FunctionalUI)
• shanselman: Repository and release history connect Scott Hanselman to recurring native application work, making this the best available routing candidate for whether the app should own a custom selection subsystem. (role: native app product and adjacent code owner; confidence: medium; files: src/OpenClaw.Tray.WinUI, src/OpenClawTray.FunctionalUI)
• ranjeshj: Recent merged history includes chat error handling and tray UX work, making this person relevant to integration and regression considerations around the native chat surface. (role: recent chat and tray contributor; confidence: medium; files: src/OpenClaw.Tray.WinUI)

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.