[Repo Assist] feat: wire WebView2 bidirectional native↔SPA bridge in WebChatWindow

[github-actions]

🤖 This is an automated PR from Repo Assist.

Implements the Windows side of the WebView2 bridge proposed in issue #191.

What changed

OpenClaw.Shared — WebBridgeMessage

New WebBridgeMessage record defining the bridge message contract:

{ "type": "...", "payload": { ... } }

• Well-known type constants matching issue [Proposal] Add a formal WebView2 bridge for native ↔ SPA communication #191's contract:
  recording-start, recording-stop, voice-start, voice-stop, draft-text, ready
• TryParse(string?) — null-safe JSON parser, returns null on malformed input
• ToJson(object?) — serialiser; runtime payload overrides stored PayloadJson

WebChatWindow.xaml.cs

SPA → native (incoming messages):

// Subscribe in InitializeWebViewAsync, unsubscribed in OnWindowClosed
WebView.CoreWebView2.WebMessageReceived += _webMessageReceivedHandler;
// Callers subscribe to:
public event EventHandler<WebBridgeMessage>? BridgeMessageReceived;

The SPA sends via window.chrome.webview.postMessage({ type, payload }) — window.chrome.webview is automatically available in WebView2-hosted pages.

Native → SPA (outgoing messages):

public void PostBridgeMessage(string type, object? payload = null)

The SPA receives via window.chrome.webview.addEventListener('message', e => { const msg = e.data; ... }).

Handler is stored in _webMessageReceivedHandler and unregistered in OnWindowClosed — no event-handler leak.

Why this matters

From issue #191 — three open PRs need this infrastructure:

PR / Feature	What it unlocks
#120 Voice Mode (NichUK)	Replace fragile DOM scraping with voice-start/voice-stop bridge messages
#159 Screen recording (AlexAlves87)	Show recording indicator in SPA via recording-start/recording-stop
Future	Push draft text to chat input via draft-text bridge message

What's NOT in scope

• Gateway/SPA side: adding window.chrome.webview.addEventListener in the gateway SPA (tracked in [Proposal] Add a formal WebView2 bridge for native ↔ SPA communication #191 as a separate repo concern)
• CanvasWindow: already has ExecuteScriptAsync channel; bridge upgrade can be a separate PR
• NodeService wiring: posting recording-start from ScreenCapability is a follow-on once the SPA side is ready

Test Status

• dotnet test OpenClaw.Shared.Tests — 648 passed, 20 skipped (↑15 from 633; 15 new WebBridgeMessageTests)
• dotnet test OpenClaw.Tray.Tests — 122 passed (unchanged)

Generated by 🌈 Repo Assist, see workflow run. 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

[AlexAlves87]

Thanks for picking up the Windows host side of the bridge from #191.

I opened the matching SPA-side draft PR here: openclaw/openclaw#69633

That PR adds the window.chrome.webview listener/ready-handshake layer on the frontend side, so both halves of the bridge can be reviewed together.

[shanselman]

Implemented the Windows WebChat side of this proposal in #192 / c7630fa.

Credit to @AlexAlves87 for the original WebView2 native ↔ SPA bridge proposal, the { type, payload } message-contract shape, and the parity rationale around avoiding DOM scraping for voice, recording indicators, draft text, and future UI-state coordination.

The merged implementation follows the core direction from this issue and adds Windows-side hardening around origin validation, dispatcher marshaling for WebView2 calls, closed-window guards, sanitized bridge logging, and payload JSON validation.