Web SDK 1.8.5 - error trying to start video for meeting in iFrame

After successfully joining a meeting with the latest web SDK (1.8.5), a user tries to enable video for their call. Instead of starting the video, the zoom sdk throws an error and does not start the video. For this particular example, the user is the only person in the meeting after starting the call and nobody else has joined. The user simply has to click the ‘start video’ button and the error occurs and video does not start. This happens about 50-60% of the time (not every time).

TypeError: Cannot read property 'width' of undefined at zoom-meeting-1.8.5.min.js:2 at redux-thunk.min.js:1 at redux.min.js:1 at zoom-meeting-1.8.5.min.js:2 at Qb (react-dom.min.js:118) at si (react-dom.min.js:131) at Q (react.min.js:11) at ta (react.min.js:12) at MessagePort.e.port1.onmessage (react.min.js:24)

Which version?

To Reproduce(If applicable)
Steps to reproduce the behavior:

  1. Call ZoomMtg.join()
  2. After meeting has started, click the ‘Start Video’ button from the web sdk UI.
  3. See error

If applicable, add screenshots to help explain your problem.

Device (please complete the following information):

  • Device: MacBook Pro
  • OS: MacOS
  • Version: 11.1
  • Browser: Chrome 87.0.4280.88

Additional context
This has been working in previous versions of the Web SDK. We encountered this after trying to upgrade the code to 1.8.5. The Zoom SDK is being hosted in an iFrame using the CDN version.

Hey @schalky,

Can you confirm you are serving both your site, and the iFrame src over https?


Yes, both the site and the iframe src are served via https.

Hey @schalky,

Are you seeing the same issue when not using an iFrame?

The Web SDK was not designed to be used inside an iFrame, so there could be issues with it.


We’ve been using it in an iFrame for the better part of a year. We verified version 1.7.10 works without issues. it just stopped working reliably when upgrading to 1.8.x. Also worth noting that if you wait for other people to join before turning on video, the problem doesn’t seem to happen.

Thanks for the info @schalky.

For an immediate resolution, please use the Web SDK on the web page directly, instead of in an iFrame.



I am working on the same project as @schalky and was the original implementor of this solution which was actually well over a year ago. We first integrated the SDK in September of 2019 with version 1.5.0 and it has been working in production for our client until the recently released 1.8.0.

Using the SDK on the web page directly is, unfortunately, NOT an immediate resolution. This would be a significant re-write of the integration and would completely break our use case of having the Zoom window display in a dialog over the main website so that attendees can view the site while they are in a meeting. Again, this has been working since version 1.5.0. What is the recent change that has broken this functionality?

If the Web SDK is indeed designed to run in a full-page view on its own then it sort of begs the question of why even have an “SDK”? This use case could be handled just fine by the web client. The entire reason that people want to integrate an SDK is to have functionality integrated visually into their existing software.


I actually think that this “black screen” issue is unrelated to running in an iFrame. I think it is actually another instance of this error:

To verify this, I set up a version of the sample web app using web SDK 1.8.5 on an independent site and had one of the users for whom the black screen issue is occurring try to join a meeting with no participants in it. When they pressed the “Video” button they received the same black screen and all of the controls disappeared.

Inspection of the DOM shows that what is going on is that the child node below the element with id="zmmtg-root" is actually being removed (along with all its descendants). This is why the whole Zoom window goes blank and probably also explains why some part of the SDK is failing to get the width of one of the DOM nodes.

Hey @ansell,

Thanks for sharing this. I have confirmed with our team that we are fixing this in the next version, 1.8.6.

We will post the release date here soon:



Thanks for the update. That’s great news that it has been confirmed and will be fixed in the next version 1.8.6. However, given that there is currently no release date for this version, is it possible to delay the planned deprecation of versions prior to 1.8.3 on January 10th?

This creates a serious issue for our users given that if we do not upgrade they will all lose audio support and if we do upgrade some unknown number of them will have issues with displaying video.
It would be much better to wait until this critical issue is resolved to deprecate the old SDK version.

Hey @ansell,

I am confirming the release date with the team. I will get back to you as soon as I can. :slight_smile:



This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.