openclaw - 💡(How to fix) Fix [Bug] macOS Companion App: Canvas A2UI push returns ok but renders completely blank (regression of #7143) [1 comments, 2 participants]

Summary

On macOS Companion App Canvas, pushing A2UI content via canvas a2ui_push returns { ok: true } from the gateway, but the Canvas (A2UI) window stays completely blank — no rendered content, no "Waiting for A2UI message" placeholder, just the empty gradient background.

Reproducible on OpenClaw 2026.4.24 (commit cbcfdf6), macOS Companion App 2026.4.24.

This appears to be a regression / still-living variant of the previously closed-as-stale issues #7143 and #22292. Filing fresh because the environment, version, and exact symptoms differ slightly from the older reports, and because side-by-side controlled testing isolates the failure cleanly to the A2UI render layer (not transport, not node connectivity, not WebView).

Controlled comparison (same node, same session, ~30s apart)

Same Mac, same paired node, both calls return success on the gateway side. Only the A2UI surface fails to render.

Reproduction

1. Pair a macOS Companion App node (status: paired · connected, caps include canvas).
2. Open the Canvas window from the Mac App; it shows the empty gradient background.
3. From the gateway host, push minimal A2UI content:

   {"surfaceUpdate":{"surfaceId":"main","components":[{"id":"hello","component":{"Text":{"text":{"literalString":"hello"},"usageHint":"h1"}}}]}}
   {"beginRendering":{"surfaceId":"main","root":"hello"}}

4. Gateway returns { ok: true }.
5. Canvas window stays blank — no text, no placeholder, no error UI.
6. As a control, push a canvas navigate to any HTTPS URL on the same node — the WebView loads the page normally, confirming the transport and WebView are healthy.

Severity

High UX, low data risk. The A2UI feature is effectively unusable on the macOS Companion App; users must fall back to the WebChat hosted-embed path to render any A2UI surfaces. Gateway-side state and transcripts are unaffected.

Where (suspected)

The render path lives behind dist/canvas-host/a2ui/a2ui.bundle.js inside the Mac App's WebView. The gateway-side push protocol (surfaceUpdate / beginRendering) is identical to the one that works correctly when the same bundle is loaded as a hosted embed inside WebChat — only the macOS App container path fails. So the failure is most likely in the Mac App's bridge/host wiring around <openclaw-a2ui-host> (e.g. applyMessages not being called with the pushed payload, or the surfaces store not being populated before the host's connectedCallback runs).

This is consistent with #7143 (Canvas stuck waiting despite successful push) and the bridge-layer hypothesis in #22292, but in this build there is no "Waiting for A2UI message" placeholder anymore — the surface stays entirely empty, which suggests the host element may not be mounting at all, or is mounting before any messages arrive and never receiving a follow-up applyMessages call.

Workaround

Render the same A2UI bundle as a WebChat hosted embed:

~/.openclaw/canvas/documents/<doc-id>/
├── a2ui.bundle.js   (copied from dist/canvas-host/a2ui/)
└── index.html       (mounts <openclaw-a2ui-host> + calls window.openclawA2UI.applyMessages([...]))

Embedded in WebChat with [embed ref="<doc-id>" ... /]. This path renders correctly and even supports user actions back to the chat session, which further confirms the bundle itself is healthy and the regression is isolated to the macOS App container.

Environment

• OpenClaw 2026.4.24 (cbcfdf6)
• macOS Companion App 2026.4.24 (hw: Mac14,7, ui: 2026.4.24)
• macOS, Apple Silicon
• Single paired node, status paired · connected, caps browser, camera, canvas, screen
• Reproduced live on 2026-04-28; not a one-off

Happy to provide additional sanitized diagnostics (full nodes status, full JSONL payload, console logs from the WebView) if it helps.