Hello Zoom Support Team,
Regarding this issue, we would like to report and confirm a screen sharing problem that occurred after upgrading the Zoom Video SDK from v2.2.5 to v2.2.12.
After the upgrade, we found an issue related to screen sharing behavior in meetings with multiple participants. We downgraded back to v2.2.5 and confirmed that the issue no longer occurs there.
1. Issue summary
After upgrading from 2.2.5 to 2.2.12, when multiple participants share their screens one after another without the previous sharer manually stopping sharing first, a participant may see a blank shared screen instead of the currently shared content.
2. Pre-conditions
3. Steps to reproduce
-
user1, user2, and user3 join the meeting.
-
user1 starts screen sharing.
- user2 and user3 can both see user1’s shared screen correctly.
-
user2 starts screen sharing without user1 manually stopping sharing first.
- user1’s sharing is stopped automatically.
- user1 and user3 can both see user2’s shared screen correctly.
-
user3 starts screen sharing without user2 manually stopping sharing first.
- user2’s sharing is stopped automatically.
- user1 and user2 can both see user3’s shared screen correctly.
-
user3 stops screen sharing.
-
user3 starts screen sharing again.
- user1 can see user3’s shared screen correctly.
- user2 sees only a blank screen.
4. Actual result
After user3 starts sharing again, user2 sees a blank shared screen.
5. Expected result
All participants, including guest users, should see the currently shared screen correctly.
6. Verification result
We downgraded the SDK from 2.2.12 back to 2.2.5 and confirmed that this issue does not occur in 2.2.5.
Because of this, we suspect the issue is related to changes introduced between 2.2.5 and 2.2.12 (possibly starting from 2.2.10).
7. Our investigation
After reviewing the SDK package code, we suspect the issue may be caused by a logic change in stopShareView() introduced in 2.2.10 and still present in 2.2.12.
Behavior in SDK 2.2.5
In 2.2.5, stopShareView() appears to always reset isReceiveSharing = false regardless of any other state.
Conceptually, it behaves like this:
stopShareView() {
if (!isReceiveSharing) return Promise.resolve("");
mediaAgent.stopRenderSharing();
rwgAgent.unsubscribeSharing(activeNodeId, isFromMainSession);
dispatch(setIsReceiveSharing(false));
return Promise.resolve("");
}
Behavior in SDK 2.2.12
In 2.2.12, stopShareView() appears to use shareViewAttachments and activeNodeId for cleanup, and isReceiveSharing is reset only when all attachments become empty.
Conceptually, it behaves like this:
stopShareView() {
if (!isReceiveSharing) return Promise.resolve("");
const dummyElements = shareViewAttachments[activeNodeId]?.filter(e => e.isDummy) || [];
if (dummyElements.length > 0) {
dispatch(removeShareViewAttachment({ userId: activeNodeId, element: dummyElements }));
}
mediaAgent.stopRenderSharing();
rwgAgent.unsubscribeSharing(activeNodeId, isFromMainSession);
const updated = getState().share.shareViewAttachments;
if (Object.entries(updated).every(([, arr]) => arr.length === 0)) {
dispatch(setIsReceiveSharing(false));
}
return Promise.resolve("");
}
Suspected root cause
Our current assumption is:
stopShareView() now depends on activeNodeId to clean up shareViewAttachments- if
activeNodeId has already been reset or changed unexpectedly, then shareViewAttachments[activeNodeId] may be undefined
- cleanup does not complete correctly
isReceiveSharing may remain stuck as true- as a result, the next sharing session may not be rendered correctly for some participants, causing a blank screen
8. Important note about source code review
The SDK source downloaded from npm appears to be obfuscated, so actual variable and function names in the package are minified/obfuscated. Our analysis above is based on reverse investigation/mapping of the package logic, not on readable original source code.
9. Our proposed workaround / fix
Our current workaround is to call:
stopShareView() beforestartShareView()
The intention is to ensure that the previous share receiving state is fully cleaned up before starting a new share view.
10. Our impact assessment of this workaround
At the moment, we believe this workaround is safe because stopShareView() in SDK 2.2.12 appears to have a safe early return:
if (!isReceiveSharing) return Promise.resolve("");
So our understanding is:
- if cleanup has already completed successfully and
isReceiveSharing = false, then calling stopShareView() again should do nothing
- if cleanup did not complete successfully and
isReceiveSharing = true, then calling stopShareView() first should help remove stale state and reset the sharing state before startShareView()
11. Questions for Zoom
Could you please help confirm the following:
-
Is our suspected root cause correct?
- Specifically, is this issue related to the logic change in
stopShareView() and the handling of shareViewAttachments, activeNodeId, and isReceiveSharing introduced after 2.2.5?
-
Is calling stopShareView() before startShareView() the correct workaround?
- Or is there any risk or side effect we should be aware of?
-
Is there an official or recommended fix from Zoom for this issue?
-
Are there any required code changes or best practices that developers should follow when upgrading from Video SDK 2.2.5 to 2.2.12, especially for screen sharing flows?
-
Has Zoom identified any known issues related to screen sharing state cleanup in versions 2.2.10 to 2.2.12?
We would appreciate your confirmation and any official guidance you can provide.
Thank you.
Best regards,
Thong