Component View: video canvas stuck at fixed small size (250x135) despite correct updateVideoOptions values; defaultViewType: 'speaker' hides meeting controls toolbar entirely

Meeting SDK
1

Hi everyone,

I’m embedding the Meeting SDK Embedded Client (Component View) inside a Next.js (App Router) web app, and I’m hitting two related rendering issues that I can’t find documentation for. Posting here after several days of debugging in case someone has run into this.

Environment

  • Zoom Meeting SDK Embedded, version 3.8.5 (loaded via https://source.zoom.us/zoom-meeting-embedded-3.8.5.min.js UMD script)
  • Next.js 15+ (App Router, Turbopack), React 19
  • client.init() is called with zoomAppRoot pointing to a plain <div>, patchJsMedia toggled on/off in testing, customize.video.isResizable: true and customize.video.viewSizes.default set

Issue 1: video canvas ignores updateVideoOptions dimensions

After client.join() succeeds, I call:

client.updateVideoOptions({
  viewSizes: {
    default: { width: finalWidth, height: finalHeight }
  }
})

Console confirms this is called with correct, large values (e.g. {finalWidth: 806, finalHeight: 584}), matching the actual size of the container div (verified via getBoundingClientRect() on the same element passed as zoomAppRoot’s parent).

However, inspecting the DOM live (Chrome DevTools → Elements) after join, I consistently find:

<canvas id="zoom-sdk-video-canvas" width="250" height="135" ...>

The canvas itself is hard-set to 250x135px regardless of what’s passed to updateVideoOptions. It’s rendered inside a <ul>/<li> structure (looks like a MUI-based gallery list — class="MuiListItem-root..."), suggesting the SDK is rendering in a “gallery” grid-tile layout where each participant gets a small fixed-size tile, and viewSizes.default isn’t controlling that tile size.

Issue 2: defaultViewType: ‘speaker’ grows the canvas but removes the entire controls toolbar

Based on the type definitions in @zoom/meetingsdk’s embedded.d.ts (SuspensionViewType enum: Minimized | Speaker | Ribbon | Gallery | Active), I tried setting:

customize: {

video: {

isResizable: true,

viewSizes: { default: { width, height } },

defaultViewType: 'speaker'

}

}

This does make the video canvas render much larger (filling most of the container), but as a side effect, the entire meeting controls toolbar (mic, camera, share screen, leave) disappears — both in a normal-sized container and in fullscreen. Only a secondary top bar (security icon + layout/view-switcher icons) remains visible; the primary control bar seems to not render at all in this view mode.

What I’ve already tried

  • Removing/adding patchJsMedia: true
  • Removing a hardcoded 16:9 letterboxing calculation in favor of filling 100% of the parent container via ResizeObserver + pure CSS (absolute inset-0 w-full h-full), no JS-driven inline styles on the container
  • Enabling Cross-Origin-Embedder-Policy: credentialless + Cross-Origin-Opener-Policy: same-origin on the relevant routes (this did fix a separate, unrelated issue where screen share content wasn’t rendering at all for any participant — now it renders, just at the wrong/small size)
  • showPureSharingContent: true in customize.opts

Question

  1. Is there a supported way to make the gallery-view participant tile (and the canvas it draws to) actually respect viewSizes.default, instead of rendering at a fixed small size?
  2. If defaultViewType: 'speaker' is the right approach for a single large “active speaker” view, is there a known reason the controls toolbar disappears in that mode, or an additional option needed to keep it visible?

Happy to share more code/screenshots if useful. Thanks in advance!

2

This seems unexpected but to confirm, you can run these two checks:

  • measure the exact element passed as zoomAppRoot, not its parent, immediately before and after calling updateVideoOptions.
  • temporarily remove overflow: hidden and give zoomAppRoot more height than the configured video because Zoom renders the toolbar and main panel into that same root. defaultViewType is init-only, but Zoom does not document speaker view as intentionally hiding meeting controls.

If both issues reproduce on the current Meeting SDK release, this seems like a bug and you have a minimal reproduction.

For meeting automation or capture outside the embedded UI, Recall.ai’s Meeting Bot API provides a managed integration path.