[Repo Assist] fix(tray): call EnableMouseInPointer(true) at startup for trackpad scroll

[github-actions]

🤖 This is an automated PR from Repo Assist.

What

Fixes two-finger trackpad scroll not working in the WinUI tray app on cloud devboxes and RDP-backed sessions.

Closes #462

Root Cause

On some cloud/VM environments (observed on Azure DevBox and RDP-backed sessions), the DirectManipulation input path used by WinUI 3's default scroll routing is absent. Without it, precision-touchpad WM_POINTER events are silently dropped, so two-finger scroll has no effect even though the same trackpad scrolls correctly in Edge/Chrome on the same machine.

The Win32 API EnableMouseInPointer(true) opts the process into the WM_POINTER codepath for mouse/touchpad events. WinUI 3 apps running in these environments need this opt-in; desktop apps have it off by default.

Fix

• Added a [DllImport("user32.dll")] P/Invoke for EnableMouseInPointer
• Added TryEnableMouseInPointer() called in App() before InitializeComponent() so the opt-in is active before any WinUI window is created
• Startup logs whether the call succeeded, failed, or was skipped
• Env var OPENCLAW_DISABLE_MOUSE_IN_POINTER=1 provides a regression-testing opt-out

Manual Verification

Shanselman applied this patch locally and confirmed in the affected dev box / RDP-style session (see comment on #462):

• Two-finger trackpad scrolling works in Settings, Chat, and Tray pages
• Mouse wheel scroll still works
• Clicks, hover, text fields, sliders, window dragging — no regressions observed

Suggested final test before merging:

1. Settings page two-finger scroll
2. Chat timeline two-finger scroll
3. Tray menu scroll, clicks, flyouts
4. Mouse wheel still works
5. Optional: launch once with OPENCLAW_DISABLE_MOUSE_IN_POINTER=1 to confirm the issue returns in an affected environment

Test Status

build.ps1 requires Windows and could not be run in CI. dotnet build on OpenClaw.Shared.Tests and OpenClaw.Tray.Tests succeeds. Tests show 8 pre-existing failures in Shared and 10 in Tray (identical to master baseline) — no new failures introduced by this change.

---

Generated by 🌈 Repo Assist. Learn more.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a

[clawsweeper]

Codex review: needs maintainer review before merge.

Latest ClawSweeper review: 2026-05-24 12:59 UTC / May 24, 2026, 8:59 AM ET.

Workflow note: Future ClawSweeper reviews update this same comment in place.

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.

Summary
The PR adds a user32 EnableMouseInPointer(true) startup opt-in in the WinUI tray app, with logging and an OPENCLAW_DISABLE_MOUSE_IN_POINTER opt-out.

Reproducibility: yes. for a reviewer with the affected Dev Box/RDP-style setup: open a scrollable tray surface on current main and try two-finger trackpad scroll. I did not reproduce it locally in this Linux read-only review, but current main lacks the proposed WM_POINTER opt-in and the linked issue has affected-session verification.

PR rating
Overall: 🐚 platinum hermit
Proof: 🐚 platinum hermit
Patch quality: 🐚 platinum hermit
Summary: Focused patch with credible linked real-environment proof, with the main remaining concern being the deliberate process-wide input-routing default change.

Rank-up moves:

• Repeat the listed input smoke on one unaffected Windows session before merge.

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

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.

Real behavior proof
Sufficient (live_output): The PR body links to an issue comment reporting after-fix testing in the affected Dev Box/RDP-style session and basic input regression smoke results.

Risk before merge

• The change opts the whole process into a different Win32 pointer input path by default, so maintainers should explicitly accept the input-compatibility risk for unaffected machines.
• This read-only review did not run Windows validation; it relies on the linked affected-session manual verification and reported local validation.

Maintainer options:

1. Merge after final input smoke (recommended)
   Accept the process-wide WM_POINTER opt-in after repeating the listed Settings, Chat, tray menu, mouse wheel, and basic input smoke on one affected session and one normal Windows session.
2. Add a narrower startup guard
   If maintainers want lower upgrade risk, add an IsMouseInPointerEnabled precheck or stronger startup diagnostics before merging the default opt-in.
3. Pause if no affected environment is available
   If the affected Dev Box/RDP setup cannot be retested, keep the PR open rather than merging an input-routing change on theory alone.

Next step before merge
No mechanical repair blocker was found; maintainer review should decide whether the linked proof and opt-out are enough for the process-wide input-routing default.

Security
Cleared: The diff only adds a Windows user32 startup P/Invoke with logging and an env opt-out; it does not change secrets, dependencies, CI, packaging, or network behavior.

Review details

Best possible solution:

Land the focused startup opt-in after maintainer acceptance of the process-wide input-routing change and final affected/unaffected Windows smoke coverage.

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

Yes for a reviewer with the affected Dev Box/RDP-style setup: open a scrollable tray surface on current main and try two-finger trackpad scroll. I did not reproduce it locally in this Linux read-only review, but current main lacks the proposed WM_POINTER opt-in and the linked issue has affected-session verification.

Is this the best way to solve the issue?

Yes, the proposed change is the narrowest code path that matches the verified local fix. The maintainer choice is whether the default process-wide opt-in plus env opt-out is the right compatibility tradeoff.

Label changes:

• add P2: This is a normal-priority tray input bug fix with limited blast radius and existing manual proof, not a core runtime emergency.
• add merge-risk: 🚨 compatibility: The PR changes process-wide pointer routing at startup, which could affect existing mouse, touchpad, or touch behavior even though the patch includes an opt-out.
• add proof: sufficient: Contributor real behavior proof is sufficient. The PR body links to an issue comment reporting after-fix testing in the affected Dev Box/RDP-style session and basic input regression smoke results.
• add rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🐚 platinum hermit, patch quality is 🐚 platinum hermit, and Focused patch with credible linked real-environment proof, with the main remaining concern being the deliberate process-wide input-routing default change.
• add status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body links to an issue comment reporting after-fix testing in the affected Dev Box/RDP-style session and basic input regression smoke results.

Label justifications:

• P2: This is a normal-priority tray input bug fix with limited blast radius and existing manual proof, not a core runtime emergency.
• merge-risk: 🚨 compatibility: The PR changes process-wide pointer routing at startup, which could affect existing mouse, touchpad, or touch behavior even though the patch includes an opt-out.
• rating: 🐚 platinum hermit: Current PR rating is 🐚 platinum hermit because proof is 🐚 platinum hermit, patch quality is 🐚 platinum hermit, and Focused patch with credible linked real-environment proof, with the main remaining concern being the deliberate process-wide input-routing default change.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (live_output): The PR body links to an issue comment reporting after-fix testing in the affected Dev Box/RDP-style session and basic input regression smoke results.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body links to an issue comment reporting after-fix testing in the affected Dev Box/RDP-style session and basic input regression smoke results.

What I checked:

• Current main lacks the opt-in: Current App() reaches InitializeComponent() without any EnableMouseInPointer, MouseInPointer, or WM_POINTER implementation found in the repo search. (src/OpenClaw.Tray.WinUI/App.xaml.cs:296, ef6ac8acbab2)
• PR diff is narrowly scoped: The patch only changes src/OpenClaw.Tray.WinUI/App.xaml.cs, adding the P/Invoke helper and calling it before InitializeComponent(). (src/OpenClaw.Tray.WinUI/App.xaml.cs:40, 40c72cf5434c)
• Affected-session proof exists: The linked issue comment reports the local patch was tested in the affected Dev Box/RDP-style session: two-finger trackpad scrolling worked, and mouse wheel, clicks, hover, text fields, sliders, and window interactions showed no obvious regressions.
• Windows-only target supports the native call scope: The tray app targets net10.0-windows10.0.22621.0 with WinUI enabled, so the added Windows user32 P/Invoke is within the app's platform boundary. (src/OpenClaw.Tray.WinUI/OpenClaw.Tray.WinUI.csproj:5, ef6ac8acbab2)
• Startup-area provenance: git blame ties the current App() startup block around InitializeComponent() to commit c417cbae...; recent App.xaml.cs history also shows follow-up startup/helper work in 190a53fb.... (src/OpenClaw.Tray.WinUI/App.xaml.cs:282, c417cbae147d)

Likely related people:

• Barbara Kudiess: git blame attributes the current App() constructor and InitializeComponent() startup block to commit c417cbae.... (role: introduced current startup block; confidence: medium; commits: c417cbae147d; files: src/OpenClaw.Tray.WinUI/App.xaml.cs)
• AlexAlves87: Recent App.xaml.cs refactor work in commit 190a53fb... extracted startup-adjacent helpers and touched the same file shortly before this PR. (role: recent area contributor; confidence: high; commits: 190a53fba49c; files: src/OpenClaw.Tray.WinUI/App.xaml.cs)
• Scott Hanselman: git shortlog shows the most commits on App.xaml.cs, and the linked issue discussion reports the proposed fix was tested in the affected session. (role: frequent area contributor and verifier; confidence: medium; commits: 33b537e7b591; files: src/OpenClaw.Tray.WinUI/App.xaml.cs)

Codex review notes: model gpt-5.5, reasoning high; reviewed against ef6ac8acbab2.

[clawsweeper]

ClawSweeper PR egg

✨ Hatched: 🥚 common Clockwork Test Hopper

Hatch command

Comment @clawsweeper hatch when this PR is hatchable.

Hatchability rules:

• Merged PRs are hatchable.
• Open PRs are hatchable when they are status: 👀 ready for maintainer look, status: 🚀 automerge armed, or labeled clawsweeper:automerge.
• Closed unmerged PRs are hatchable only when one of those hatchable labels is still present in the durable record.

Rarity: 🥚 common.
Trait: stacks clean commits.
Image traits: location review cove; accessory review stamp; palette plum, gold, and soft gray; mood curious; pose balancing on a branch marker; shell brushed metal shell; lighting gentle morning glow; background soft code-shaped tiles.
Share on X: post this hatch
Copy: My PR egg hatched a 🥚 common Clockwork Test Hopper in ClawSweeper.

What is this egg doing here?

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.