runRenderingContext({view: 'camera'}) + drawWebView silently no-op on Zoom Workplace 7.0.2 — related to ZSEE-195647?

Zoom Apps
1

Summary

On Zoom Workplace 7.0.2 (Windows), `runRenderingContext({view: ‘camera’})` followed by `drawWebView(…)` both resolve successfully, but nothing renders on the host’s camera feed. No overlay, no IPC, no ping from the camera context. This looks very similar to the regression tracked under **ZSEE-195647** (forum thread: *Virtual streamer overlay text on camera not showing after zoom update*, reported Dec 24, 2025).

I hit the same symptom on 6.7.8.32670 — upgraded to 7.0.2 hoping the fix had landed — same failure, different failure mode (see diagnostics below).

Looking for confirmation on whether this is still the same ticket, an adjacent regression, or a Marketplace configuration problem.

Environment

Item Value
Zoom client 7.0.2 (Windows) — upgraded from 6.7.8.32670
@zoom/appssdk 0.16.37
App type Zoom App running in-meeting sidebar + camera rendering context
OS Windows 10 Pro 19045
Browser UA reported by webview Chrome/147.0.0.0
Host URL Served over HTTPS via ngrok reserved domain (confirmed matches Marketplace Home URL, OAuth Redirect, and Domain Allow List)
App is permitted to use runRenderingContext, closeRenderingContext, drawWebView, clearWebView, drawParticipant, clearParticipant, postMessage, onMessage, getRunningContext, getUserContext, onMyMediaChange, plus meeting-only APIs

Minimum repro (sidebar context)

// 1. config succeeds on first attempt, context is 'inMeeting'
await zoomSdk.config({ capabilities: [
  'runRenderingContext', 'closeRenderingContext',
  'drawWebView', 'clearWebView',
  'postMessage', 'onMessage',
  'getRunningContext', 'getUserContext',
  // ...meeting caps
]});

// 2. Register onMessage listener for ready ping from camera context
zoomSdk.addEventListener('onMessage', (e) => console.log('sidebar onMessage', e));

// 3. Start camera rendering context — resolves success
await zoomSdk.runRenderingContext({ view: 'camera' });
//    getRunningContext() on sidebar still reports 'inMeeting' (expected)

// 4. Push overlay HTML into camera context via data: URL (bypasses external HTTP sandbox)
const dataUrl = 'data:text/html;charset=utf-8,' + encodeURIComponent(`
  <html><body style="background:rgba(255,0,0,0.35)">
    <div style="background:lime;color:#000;font:900 48px monospace;padding:20px">
      DRAWWEBVIEW OK
    </div>
    <script src="https://appssdk.zoom.us/sdk.min.js"></script>
    <script>
      ZoomSdk.config({capabilities:['onMessage','postMessage']})
        .then(() => ZoomSdk.postMessage({type:'camera-overlay-ready'}));
    </script>
  </body></html>
`);

await zoomSdk.drawWebView({
  webviewId: 'overlay-1',
  url: dataUrl,
  x: 0, y: 0, width: 1280, height: 720,
  zIndex: 2,
});
// ✓ resolves success, no error

Expected

  • Host’s camera feed shows a translucent red tint with a bright lime “DRAWWEBVIEW OK” banner at top

  • Camera context loads the data: URL, calls ZoomSdk.config(), and posts camera-overlay-ready

  • Sidebar’s onMessage handler receives the ping

Actual

  • Host’s camera feed is unchanged — nothing visible at all

  • Sidebar’s onMessage handler never fires — no camera-overlay-ready ping

  • Subsequent zoomSdk.postMessage(...) calls from the sidebar all resolve success but go nowhere (no onMessage event ever fires in any context)

  • Teardown via closeRenderingContext() succeeds cleanly

No errors thrown, no SDK error codes, no console warnings. Every SDK call returns success.

Diagnostic signal: hybrid IPC bridge behaviour changed between 6.7.x and 7.0.2

I logged all HTTP traffic on the web origin via ngrok’s request inspector.

On Zoom client 6.7.8.32670:

  • After runRenderingContext, the Zoom client sends POST /zoom_unifywebview_hybrid_ipc?callid=N requests out to the web origin (our ngrok host). These are clearly internal client<->webview IPC calls leaking out of the native bridge — and returning 404 from Express since the app doesn’t handle them.

  • Symptom in app: overlay never renders, postMessage between sidebar and camera context errors with "Failed to post message to connected app."

On Zoom client 7.0.2:

  • POST /zoom_unifywebview_hybrid_ipc requests no longer leak to the web origin — looks like the native IPC interception is now working again.

  • Symptom in app: overlay still never renders, but postMessage no longer errors — it resolves success and vanishes.

So something did change between 6.7.x and 7.0.2, but the end-user behaviour (no overlay) is still broken.

What I ruled out

  • Marketplace config mismatch — Home URL, OAuth Redirect URL, Domain Allow List all match the ngrok domain exactly

  • Ngrok tunnel down / URL drift — reserved domain, tunnel verified healthy

  • External script CSP — switched from loading a hosted overlay URL to a self-contained data: URL; drawWebView still silent no-op

  • SDK CDN script loading — even a pure HTML+CSS data URL with zero JS produces no visible render

  • Lifecycle / ordering — tried listener-before-runRenderingContext, retry loops for SDK init, multiple drawWebView patterns; no change

The drawWebView call itself returns success in every case. I have no way to verify from the sidebar whether the camera context webview was actually created.

Questions

  1. Is this the same regression as ZSEE-195647? If so, is there a status update beyond Feb 24, 2026?

  2. Is there a known-good Zoom client version for runRenderingContext({view: 'camera'}) + drawWebView on Windows right now?

  3. Are there additional Marketplace surface settings beyond Home URL / OAuth Redirect / Domain Allow List that must be declared for an app to use the camera rendering context? (e.g. a separate camera surface Home URL, or an immersive mode toggle I may be missing)

  4. Is there a way to attach Chrome DevTools (or any debugger) to the off-screen-rendering webview spawned by runRenderingContext({view: 'camera'})? Without that, drawWebView is a complete black box when it fails silently.

  5. Is there a supported API / event that confirms the OSR webview was actually created and navigated to the URL — something more than drawWebView resolving?

Happy to share additional logs, ngrok traces, or a reduced-repro build if useful.

Thanks.

2

Requesting to delete this post.

Solution was found by using drawImage method instead of drawWebView.