[Zoom Web Meeting SDK v.2.3.0] Both guest and host audio and video stopped working right after the host started screen sharing

Meeting SDK Web
1

Description
After we upgraded our app to use Zoom Web SDK 2.3.0, we received reports from multiple users wherein both users audio and video suddenly working right after the host starts the screen sharing. For some of the users they also experienced “black screen”, wherein the buttons and video are suddenly gone. For some, the screen becomes unresponsive as well.

Steps to replicate the issue

  1. Both client (guest) and instructor (host) join the meeting
  2. Enable both video and audio
  3. Instructor clicks on “Share Screen” > “Share” button

Expected Result:

The instructor’s screen is shared with the client with both the audio and video still working on both users.

Actual Result:

Both users’ screens froze and the video and audio stopped working on both sides.

Note:

They both left the meeting after encountering the issue and rejoined again. When the instructor tried to share his/her screen again, the same issue happened. It happened to 7 meetings already on March 23 for different users, devices, and locations.

Logs

We are not sure if the following are related to the issue but we saw these matches the timing the issue happened. We are still seeing these logs even after upgrading to Web SDK v.2.3.5.

NotFoundError: Failed to execute 'insertBefore' on 'Node': The node before which the new node is to be inserted is not a child of this node. 
webpack:///./node_modules/@zoomus/websdk/node_modules/react-dom/cjs/react-dom.development.js? at line 8862 webpack:///./node_modules/@zoomus/websdk/node_modules/react-dom/cjs/react-dom.development.js? at line 17776 
webpack:///./node_modules/@zoomus/websdk/node_modules/react-dom/cjs/react-dom.development.js? at line 18655 
webpack:///./node_modules/@zoomus/websdk/node_modules/react-dom/cjs/react-dom.development.js? at line 149 webpack:///./node_modules/@zoomus/websdk/node_modules/react-dom/cjs/react-dom.development.js? at line 199 
webpack:///./node_modules/@zoomus/websdk/node_modules/react-dom/cjs/react-dom.development.js? at line 256 webpack:///./node_modules/@zoomus/websdk/node_modules/react-dom/cjs/react-dom.development.js? at line 18913 
webpack:///./node_modules/@zoomus/websdk/node_modules/react-dom/cjs/react-dom.development.js? at line 20418 
webpack:///./node_modules/scheduler/cjs/scheduler.development.js? at line 255 
webpack:///./node_modules/@zoomus/websdk/node_modules/react-dom/cjs/react-dom.development.js? at line 20417

=======================================

And this is from chrome logs,

=======================================

[media_stream_audio_processor.cc(656)] Large audio delay, capture delay: 20.143ms; render delay: 354.395ms

=======================================

Which Web Meeting SDK version?
Web SDK 2.3.0

Device (please complete the following information):

  • Chrome OS v99, v100
  • Windows 10
  • macOS 10.15.17

Additional context
Zoom Support Ticket: https://support.zoom.us/hc/en-us/requests/13900548

2

This issue continue to happen after upgrading to the Web SDK 2.3.5.

@donte.zoom

Zoom’s support recommended us to deactivate Hardware acceleration on Chrome settings to see if it improve / resolve that situation. Honestly we are a bit tired of having to test anything on our own with that feeling that the support is just buying some time / luckily fixing the issue without really knowing the root cause.

We would like the opinion of Zoom developers on that matter.

  • This started with the release 2.3.0 so this is something recently introduced and so far not related to a specific version of Chrome since there was no update of Chrome at that time. Does this new buggy behavior ring a bell according to changes made on the latest web SDK releases or on Web backend maintenance of Zoom servers over the last 4 weeks ?
  • Is deactivating the hardware acceleration on Chrome really supposed to improve things with the Zoom Web SDK?
3

Greetings

Thanks for the tag @nvivot and @lfrancia! It looks like the ticket is still open and support is still actively working towards a resolution. Please kindly continue to work with our support team. I’ve reviewed the ticket and see you are in good hands. Be sure to pass along your questions and feedback to our support to share with the developer team as well. Your feedback is the driving force to helping us better the developer experience.

We appreciate you working with us !

Regards,
Donte

4

@donte.zoom

We are addressing a bug in the Web SDK, so the forum (here) is the place to report it according to your support.

There is a clear error stack referring to the Zoom Web SDK, reported from the beginning.
I copy / paste that again here to make sure you did not miss anything.

image
image776×626 95.6 KB

This is a clearly a bug on Zoom Web SDK.

How / when that happens ?

On a 1 on 1 meeting, with participant A and B, when participant A (host) start to do a screen share, this javascript error stack occurs on the browser of participant B (non host)

Note that this does not systematically happens. Looking at the stack trace, it really looks like this depends on the interaction with the DOM between the Zoom Web SDK react library, and the one important & use by our application.

We never got such integration issue by the past, which means something changed with the 2.3.0 (we did not upgrade any of our dependencies than the zoom SDK at the time we released our application with the newer SDK)

History of this issue

We explained that this started to appear with the release 2.3.0 where a very hard dependency on the embedded react js library from the zoom sdk sources has been introduced (looks like so for me)

We reported that the release 2.3.0 was totally broken for any ReactJS based application using the Zoom Web SDK, and you proposed a workaround that forced us to import the react js library version the Zoom SDK requires directly into our own application HTML pages (as a script import)

And since that, this issue started to happen.

After upgrading to the 2.3.5, we removed that workaround, but this error did not disappear, which means that the problem is there since changes introduced in 2.3.0.

What is wrong with the current Zoom Web SDK packaging

Your SDK package includes a hard dependency on a react js library, used for the UI components of the SDK itself.

For applications not using react JS, i believe this is “ok” ~ ish, since no other react js engine is imported in the application.
But for application developed with Node.js / React.js and packaging their sources with the node/react library, this is an issue as two potential different components are affecting DOM elements and conflict each others.

What’s even worse in this pattern is that the Zoom Web SDK react library is completely outdated and not maintained.
When compiling / package a node/react web application using this Zoom SDK, it’s pretty obvious since a warning message is printed about this SDK requiring a fixed version of the react-dom packages…

Not only this is a sources of integration issues, but a strong security problem as well as Zoom never upgrade its dependencies.

Conclusion

It would be very helpful if instead of asking us to spend months debugging situation for you with very high support layers, you as developer start to have a serious look at all the javascript errors generated by this Web SDK when using React JS in the final application (you have a zoom sample web application using React JS where all these reported issue happens so you can easily replicate it & figure what’s wrong)

We reported tons of these javascript react errors, new ones constantly appears with each new release of this SDK, which means that you never test it with React as it’s so easy to spot it that you should find it during development phases.

2 Likes
5

We could finally reproduce this issue 100% of the time and so we have new elements for you.

Conditions to reproduce it: Having the google translate chrome extension and configuring the translation with a default language different than english (japanese in the case of our users). The auto translation of our application pages then would occurs as we enforce the language to “en” in the HTML tag of our application pages.

How to reproduce it within the SDK sample app: Just enforce the language to “en” (as example) in the HTML tag of the sample web app, and configure the google translation extension on Chrome.

The bug is trigered by the google translate extension modyfing the DOM tree in a way to crash React.

This is a very well known issue, and unfortunately if we can easily avoid it with the google translate extension by seeting a property translate=“no” in the main HTML tag, any other chrome extension modifying the DOM can cause the exact same issue.
(see this reported bug as a recent example, but there are plenty)

This happens a lot with 3rd party translation extension as they are modifying text elements.
The issue happens when any application or SDK modify the DOM to include text in fragment element instead of wrapping these text in appropriate dom elements.

The cause of this error from the web SDK 2.3.0:

Since there were no dependency upgrade on the react library embed with Zoom SDK for years, i suspect that you introduced some UI refactoring with the 2.3.0 by adding some text elements directly in fragment without wrapping it in real dom elements, thus now provoking this issue for users using translation extension.
To be more specific in where this UI refactoring may have been done, since this error happen when someone start to do a screen share, then it should be on Zoom SDK code triggered when changing the UI for a screen sharing.

@donte.zoom
Could you please review the SDK UI elements built in the different scenario and make sure they are correctly wrapped (for example within a span element) in order to avoid any conflict introduced by translation extensions ?

1 Like
6

@nvivot,

Thanks for the tag, and I appreciate the detailed description of the behavior you are encountering. Please allow me some time to reproduce and share my finding with the SDK team.

7

@donte.zoom

As a workaround, we added the property translate=“no” to the main HTML tag in all our HTML pages.

This property can also be added to any HTML elements, so we could also just wrap the root HTML element the Zoom SDK is embed in. Might be an option if you want to avoid the Zoom part to be translated by any extension.

8

up with at least twenty characters

9

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