[Bug]: Shift+Enter in chat composer moves caret to start of text instead of inserting newline

[SamuelThornburg]

Version: OpenClaw Companion 2026.9.4 (3c43751), Windows x64. Code path unchanged on main @ a2c4647. Gateway 2026.9.5.

Steps

1. Open chat in the companion app.
2. Type hello world, leave the caret at the end.
3. Press Shift+Enter.

Expected

A newline is inserted at the caret and the caret moves to the new line (as in the web Control UI).

Actual

The caret jumps to position 0, above/before the existing text.

Analysis (from reading the source; not debugged live)

src/OpenClaw.Tray.WinUI/Chat/ReactorChatComposer.cs (~L480–566) uses AcceptsReturn(false) and handles Shift+Enter manually in OnKeyDown: it sets args.Handled = true, calls vm.SetDraft(current[..start] + "\n" + current[end..]), then sets textBox.SelectionStart = start + 1.

ChatComposerViewModel.SetDraft is enqueued via Mutate/EnqueueMutation, so the selection is set against the stale text. When the queued draft re-renders, TextBox.Text is replaced wholesale and WinUI resets the selection to 0. WinUI's \n → \r normalization may also make the read-back text never equal the draft, causing an extra re-sync.

Introduced with the chat composer rewrite (#1055 / #1098).

Suggested fix

Use AcceptsReturn(true) and only intercept unmodified Enter (set Handled, call Send()), letting the TextBox insert newlines natively. Alternatively, defer caret placement until after the draft commits and compare drafts with normalized line endings.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 23, 2026, 1:13 AM ET / 05:13 UTC.

Summary
Keep open and route to a focused repair. The caret is positioned before Reactor commits the updated text, and both current main and the latest release retain this ordering. No existing fix PR was found.

Reproducibility: yes. source establishes the ordering defect for typing hello world and pressing Shift+Enter at the end: caret placement precedes the queued text render. The exact reported jump to zero and newline normalization were not executed or independently observed in this read-only review.

Next step
A focused composer repair has a source-established ordering defect, an existing native test seam, and no open PR owning the fix; establish a failing native regression before implementation.

Review details

Best possible solution:

Let the native TextBox own newline insertion and caret movement while preserving Enter-to-send, slash-menu behavior, and the existing draft ownership boundary.

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

Yes, source establishes the ordering defect for typing hello world and pressing Shift+Enter at the end: caret placement precedes the queued text render. The exact reported jump to zero and newline normalization were not executed or independently observed in this read-only review.

Is this the best way to solve the issue?

Yes, native newline insertion is the narrowest promising repair because it avoids placing the caret against stale text. A real WinUI regression must verify the result after rendering and preserve existing send and slash-menu semantics.

AGENTS.md: found and applied where relevant.

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

Label changes

Label changes:

• add P2: This is a bounded defect in native multiline composition, without evidence that ordinary chat sending is blocked.
• add impact:ux-friction: Shift+Enter disrupts caret placement while composing a multiline message.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:queueable-fix: Current issue advisory state selects this label.
• add clawsweeper:fix-shape-clear: Current issue advisory state selects this label.

Label justifications:

• P2: This is a bounded defect in native multiline composition, without evidence that ordinary chat sending is blocked.
• impact:ux-friction: Shift+Enter disrupts caret placement while composing a multiline message.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• .\scripts\run-proof-tests.ps1 -Project 'tests\OpenClaw.Tray.UITests\OpenClaw.Tray.UITests.csproj' -Filter 'FullyQualifiedName~ReactorChatLayoutProofTests' -ResultName 'composer-keyboard' -RuntimeIdentifier win-x64
• .\scripts\run-proof-tests.ps1 -Project 'tests\OpenClaw.Tray.UITests\OpenClaw.Tray.UITests.csproj' -Filter 'Category=Accessibility' -ResultName 'winui-accessibility' -RuntimeIdentifier win-x64

What I checked:

• Current source retains premature caret placement: The Shift+Enter handler suppresses native input, updates only the view-model draft, and immediately sets SelectionStart on the existing TextBox. AcceptsReturn remains false. The draft reaches the rendered TextBox through the PropertyChanged-driven Reactor state update. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatComposer.cs:550, a2c4647d4289)
• Correction to the reported mechanism: EnqueueMutation drains synchronously when the caller has UI-thread access and no drain is already scheduled. Therefore, the defect should not be described as an invariably deferred view-model mutation: the independently queued Reactor render is the relevant text-application boundary. (src/OpenClaw.Tray.WinUI/Chat/ChatComposerViewModel.cs:358, a2c4647d4289)
• Direct dependency contract: The WinUI application references Microsoft.UI.Reactor 0.1.0-preview.12; ReactorChatComposer uses its TextBox factory and UseState render invalidation. This establishes the dependency signal for inspecting Reactor's scheduling behavior. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:104, a2c4647d4289)
• Pinned dependency confirms deferred rendering: Repository ownership and the preview.12 tag were verified through GitHub. At that tag, UseState requests a rerender, and ReactorHostControl.RequestRender queues RenderLoop through DispatcherQueue.TryEnqueue. Thus SetDraft cannot make the new TextBox contents available before the immediately following caret assignment in the key handler. (src/Reactor/Hosting/ReactorHostControl.cs:262, b2a71d4ba0d8)
• Latest release retains the affected handler: GitHub reports v2026.9.4 as the latest release. Its composer contains the same SetDraft-before-SelectionStart sequence and AcceptsReturn(false). A separate live branch query confirmed main still points to the reviewed checkout SHA. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatComposer.cs, 3c43751b2bac)
• Existing native test seam: ReactorChatLayoutProofTests mounts the production chat surface and locates ChatComposerInput as a real TextBox. Existing assertions cover draft contents and layout, but the inspected tests do not exercise Shift+Enter or verify its caret after rendering. (tests/OpenClaw.Tray.UITests/ReactorChatLayoutProofTests.cs:113, a2c4647d4289)

Likely related people:

• bkudiess: 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.