[Repo Assist] feat(canvas): F11 borderless fullscreen toggle for Canvas windows

[github-actions]

🤖 This is an automated pull request from Repo Assist.

Closes #669

Summary

Adds F11/Escape keyboard shortcut to toggle borderless fullscreen in both Canvas window types:

• CanvasWindow — WebView2-based canvas
• A2UICanvasWindow — native XAML A2UI canvas

Root Cause

Neither Canvas window implemented a fullscreen presenter. The WinUI 3 AppWindow API (Microsoft.UI.Windowing) provides SetPresenter(AppWindowPresenterKind.FullScreen) / SetPresenter(AppWindowPresenterKind.Default) which handles fullscreen cleanly without manual Win32 ShowWindow tricks.

Fix Rationale

A2UICanvasWindow

KeyboardAccelerators registered on RootGrid handle F11/Escape directly from the XAML tree. This is the standard WinUI pattern (same as ChatWindow).

CanvasWindow (WebView2)

Two-layer approach required because WebView2 captures keyboard input at Win32 level when focused, bypassing XAML accelerators:

1. XAML KeyboardAccelerators on the root content element — handles F11/Escape when the title bar or any XAML element has focus.
2. JavaScript injection via AddScriptToExecuteOnDocumentCreatedAsync — a content script listens for keydown on document (capture phase) and posts bridge messages (fullscreen-toggle, fullscreen-exit) when WebView2 has focus. These are intercepted in the existing WebMessageReceived handler before forwarding to BridgeMessageReceived subscribers, so web content is unaffected.

Shared logic

Both windows use AppWindow.SetPresenter() (inherited from WindowEx → Window), _isFullScreen guard flag, and ExitFullScreen() called in the Closed handler with try/catch to handle window-destruction timing.

Trade-offs

• The JS injection approach for CanvasWindow is a clean established pattern for bridging native keyboard shortcuts into WebView2 content.
• fullscreen-toggle / fullscreen-exit bridge types are handled internally and never reach BridgeMessageReceived subscribers — intentional so existing consumers see no new message types.
• No new NuGet dependencies; Microsoft.UI.Windowing is already part of Microsoft.WindowsAppSDK.

Test Status

Tray tests: Passed! - Failed: 0, Passed: 990, Skipped: 2, Total: 992 ✅

Shared tests: 8 pre-existing failures in MxcConfigBuilderTests for Windows drive-root path checks running on Linux (C:\ vs /) — unrelated to this change. ✅

Build validates cleanly with GITHUB_ENV=/tmp/gh-aw/agent/github_env dotnet test /p:EnableWindowsTargeting=true.

Note: The full build.ps1 (PowerShell + GitVersion) cannot run in the Linux agent environment, as GitVersion requires the GitHub Actions runner file-command paths. All compilation and unit tests pass.

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

Add this agentic workflows to your repo

To install this agentic workflow, run

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

[clawsweeper]

Codex review: needs changes before merge. Reviewed June 10, 2026, 10:06 AM ET / 14:06 UTC.

Summary
The PR adds AppWindow-based F11/Escape borderless fullscreen toggles to the WebView2 and native A2UI Canvas windows.

Reproducibility: yes. for the introduced PR defect: focus WebView2 and press F11 or Escape; source inspection shows the injected code sends a string root to the existing object parser. The linked fullscreen request itself is a feature, not a bug reproduction.

Review metrics: 2 noteworthy metrics.

• Canvas surface: 2 files changed. The feature spans two distinct input stacks: native XAML and WebView2.
• Broken bridge calls: 2 calls. Both WebView-focused shortcuts use the incompatible JSON-string payload format.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🦪 silver shellfish
Result: blocked until real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Send JavaScript objects directly through the WebView bridge and add focused regression coverage.
• Post a redacted Windows recording covering F11 toggle and Escape exit with XAML and WebView focus in both Canvas window types.

Proof guidance:

• [P1] Needs real behavior proof before merge: The PR reports compilation and tests but provides no after-fix Windows recording, screenshot, live output, or logs showing the fullscreen transitions and focus-dependent shortcuts; redact private endpoints or identifiers, update the PR body after adding proof, and request @clawsweeper re-review if automatic review does not rerun.

Mantis proof suggestion
A native Windows recording would directly verify the visible fullscreen transition and both focus-dependent keyboard paths after the bridge repair. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

visual task: after the bridge fix, record both Canvas window types entering/toggling fullscreen with F11 and exiting with Escape, including WebView2 and native-control focus.

Risk before merge

• [P1] With WebView2 focused, F11 and Escape do not reach the new native fullscreen branches because their posted values violate the established bridge format.
• [P1] The string-root payload can raise an unhandled InvalidOperationException in the WebMessageReceived event path, potentially terminating the tray process.
• [P1] The PR lacks real Windows evidence for F11 toggling, Escape exit, WebView focus, native-control focus, multi-monitor behavior, and restoration of the prior window state.

Maintainer options:

1. Fix the WebView payload (recommended)
   Send JavaScript objects directly for both shortcuts and add regression coverage for parsing and internal dispatch before merge.
2. Remove WebView-focused shortcuts
   Drop the injected WebView path and retain only native XAML accelerators if maintainers accept shortcuts not working while WebView2 has focus.
3. Pause pending Windows validation
   Leave the draft open until the repaired behavior is demonstrated in both Canvas window types on a real Windows setup.

Copy recommended automerge instruction

@clawsweeper automerge

Special instructions:
In CanvasWindow's injected shortcut script, send JavaScript objects directly through window.chrome.webview.postMessage instead of JSON.stringify, and add focused regression coverage for both internal fullscreen message types.

Next step before merge

• [P2] A narrow mechanical bridge repair is clear and automatable; contributor or maintainer real Windows proof remains required before merge.

Security
Cleared: No concrete security or supply-chain regression was found in this focused first-party UI change.

Review findings

• [P1] Send bridge objects instead of JSON strings — src/OpenClaw.Tray.WinUI/Windows/CanvasWindow.xaml.cs:324-326

Review details

Best possible solution:

Keep the AppWindow presenter design, send bridge objects directly from JavaScript, add focused regression coverage for both internal messages, and prove both Canvas implementations on Windows before merge.

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

Yes for the introduced PR defect: focus WebView2 and press F11 or Escape; source inspection shows the injected code sends a string root to the existing object parser. The linked fullscreen request itself is a feature, not a bug reproduction.

Is this the best way to solve the issue?

No, not as written; AppWindow presenters are the appropriate window-level mechanism, but the WebView bridge must send objects directly and receive Windows runtime validation.

Full review comments:

• [P1] Send bridge objects instead of JSON strings — src/OpenClaw.Tray.WinUI/Windows/CanvasWindow.xaml.cs:324-326
  Pass { type: 'fullscreen-toggle' } and { type: 'fullscreen-exit' } directly to postMessage. WebMessageAsJson already serializes the posted value, so stringifying first makes the root a string; WebBridgeMessage.TryParse cannot read type, breaking both WebView-focused shortcuts and potentially throwing from the event handler.
  Confidence: 0.99

Overall correctness: patch is incorrect
Overall confidence: 0.99

AGENTS.md: found and applied where relevant.

Codex review notes: reasoning high; reviewed against 0e61fa287afb.

Label changes

Label changes:

• add P3: Borderless Canvas fullscreen is an optional presentation enhancement with limited urgency.
• add merge-risk: 🚨 availability: Pressing the new shortcuts with WebView focus can feed a string root to an object-only parser and cause an unhandled UI event exception.
• add rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• add status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR reports compilation and tests but provides no after-fix Windows recording, screenshot, live output, or logs showing the fullscreen transitions and focus-dependent shortcuts; redact private endpoints or identifiers, update the PR body after adding proof, and request @clawsweeper re-review if automatic review does not rerun.
• remove rating: 🌊 off-meta tidepool: Current PR rating is rating: 🧂 unranked krab, so this older rating label is no longer current.

Label justifications:

• P3: Borderless Canvas fullscreen is an optional presentation enhancement with limited urgency.
• merge-risk: 🚨 availability: Pressing the new shortcuts with WebView focus can feed a string root to an object-only parser and cause an unhandled UI event exception.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🦪 silver shellfish.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: The PR reports compilation and tests but provides no after-fix Windows recording, screenshot, live output, or logs showing the fullscreen transitions and focus-dependent shortcuts; redact private endpoints or identifiers, update the PR body after adding proof, and request @clawsweeper re-review if automatic review does not rerun.

Evidence reviewed

Acceptance criteria:

• [P1] ./build.ps1.
• [P1] dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore.
• [P1] dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore.

What I checked:

• Blocking WebView bridge defect: Both injected shortcuts call postMessage with JSON.stringify, producing a JSON string root instead of the object expected by the existing Canvas bridge. (src/OpenClaw.Tray.WinUI/Windows/CanvasWindow.xaml.cs:324, 81b07bea0c62)
• Object-only bridge parser: WebBridgeMessage.TryParse calls TryGetProperty on the JSON root; a string root cannot provide the required type property and may raise InvalidOperationException. (src/OpenClaw.Shared/WebBridgeMessage.cs:65, 0e61fa287afb)
• Supported XAML accelerator precedent: Current ChatWindow attaches hidden KeyboardAccelerators to its root FrameworkElement, supporting the native XAML portion of the proposed approach. (src/OpenClaw.Tray.WinUI/Windows/ChatWindow.xaml.cs:96, 0e61fa287afb)
• Feature remains absent from main: Current main has no fullscreen presenter or F11 handling in either Canvas implementation, so this PR addresses an open feature rather than duplicating existing behavior. (src/OpenClaw.Tray.WinUI/Windows/CanvasWindow.xaml.cs:231, 0e61fa287afb)
• Repository validation policy: AGENTS.md requires the full Windows build plus shared and tray test projects after code changes; the PR body reports Linux-targeted validation but no complete Windows run or runtime proof. (AGENTS.md:3, 0e61fa287afb)
• Clean read-only review: The checkout remained unchanged throughout the review. (0e61fa287afb)

Likely related people:

• Scott Hanselman: Current file history attributes recent hardening of CanvasWindow and its WebView behavior to this contributor. (role: recent WebView Canvas contributor; confidence: medium; commits: d23f8ca50013; files: src/OpenClaw.Tray.WinUI/Windows/CanvasWindow.xaml.cs)
• Christine Yan: Current-main history attributes the native A2UICanvasWindow implementation and most of its lifecycle behavior to this contributor. (role: A2UI Canvas feature contributor; confidence: high; commits: 85445c78066b; files: src/OpenClaw.Tray.WinUI/Windows/A2UICanvasWindow.xaml.cs)
• RBrid: Recent current-main history modified close-time teardown and exception handling adjacent to the proposed fullscreen restoration. (role: recent A2UI lifecycle contributor; confidence: high; commits: 753828f63e96; files: src/OpenClaw.Tray.WinUI/Windows/A2UICanvasWindow.xaml.cs)

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.

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.