fix(meetings): prevent stale whiteboard share event during content handoff by mickelr · Pull Request #4958 · webex/webex-js-sdk

mickelr · 2026-05-06T09:53:35Z

Summary

Fix share-state handling when whiteboard is released while a new content share is still in an intermediate non-GRANTED disposition such as ACCEPTED
Ensure this transition resolves to NO_SHARE instead of keeping stale WHITEBOARD_SHARE_ACTIVE
Add regression coverage for whiteboard -> file/content share handoff so we do not re-emit MEETING_STARTED_SHARING_WHITEBOARD

Why

When a whiteboard share is released and the next content share arrives as ACCEPTED before GRANTED, the previous logic left newShareStatus unchanged. That could re-fire whiteboard start events with a stale/released whiteboard URL before the real remote share starts.

Test

source ~/.nvm/nvm.sh
nvm use 22.14
yarn workspace @webex/plugin-meetings test:unit --targets meeting/index.js

Focused run with temporary .only on share scenarios:

28 passing (116ms)

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8cb600a29a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-05-06T11:31:43Z

+      else {
        newShareStatus = SHARE_STATUS.NO_SHARE;


Preserve local state until remote grant

When a local content share is active and Locus sends an intermediate ACCEPTED update for another participant before the final GRANTED, this default branch changes shareStatus to NO_SHARE. The subsequent GRANTED update then starts remote sharing with oldShareStatus === NO_SHARE, so the existing steal-handling path that calls unpublishStreams() only when oldShareStatus === LOCAL_SHARE_ACTIVE is skipped; the local share tracks can remain published after a remote participant takes the floor. This branch should avoid clearing a local active content share on an intermediate accepted handoff, or otherwise preserve enough state to unpublish on the final remote grant.

Useful? React with 👍 / 👎.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 6ba0ac4877

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-05-06T13:01:44Z

+        this.shareStatus === SHARE_STATUS.LOCAL_SHARE_ACTIVE &&
+        contentShare.disposition === FLOOR_ACTION.ACCEPTED


Preserve remote shares during ACCEPTED handoffs

When an existing remote content share is active and another participant's floor update arrives as ACCEPTED before the final GRANTED, this exception does not apply because it only preserves LOCAL_SHARE_ACTIVE; the new default branch then sets NO_SHARE. In that remote-to-remote handoff scenario the listener emits MEETING_STOPPED_SHARING_REMOTE and loses the REMOTE_SHARE_ACTIVE state before the final grant, bypassing the remote-steal path below that is specifically meant to handle one remote presenter taking over from another without stopping the share.

Useful? React with 👍 / 👎.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: e956efc64c

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-05-06T13:46:01Z

      else if (
-        ((previousContentShare && contentShare.disposition === FLOOR_ACTION.RELEASED) ||
-          contentShare.disposition === null) &&
-        ((previousWhiteboardShare && whiteboardShare.disposition === FLOOR_ACTION.RELEASED) ||
-          whiteboardShare.disposition === null)
+        (this.shareStatus === SHARE_STATUS.LOCAL_SHARE_ACTIVE ||
+          this.shareStatus === SHARE_STATUS.REMOTE_SHARE_ACTIVE) &&
+        contentShare.disposition === FLOOR_ACTION.ACCEPTED


Preserve only real content shares on ACCEPTED

When a webinar attendee or guest is viewing a whiteboard, the earlier whiteboard branch stores it as REMOTE_SHARE_ACTIVE; if that whiteboard is then RELEASED while the next content floor is only ACCEPTED, this new preservation branch treats the whiteboard-backed remote state as an active content share. In that context the listener skips the transition to NO_SHARE and the accepted-event path below is also suppressed, so the stale whiteboard/remote state remains until the final GRANTED update instead of stopping the released whiteboard as intended. Please gate this preservation on the previous/current content floor actually representing an active content share, not just on the shared REMOTE_SHARE_ACTIVE status.

Useful? React with 👍 / 👎.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 05bf5bb730

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-05-07T01:58:49Z

+      } else if (
+        newShareStatus === SHARE_STATUS.REMOTE_SHARE_ACTIVE &&
+        contentShare.disposition !== FLOOR_ACTION.ACCEPTED
+      ) {


Preserve previous presenter for member updates

When a content handoff goes through ACCEPTED, this branch now suppresses locusMediaSharesUpdate until the final GRANTED update, but that final payload has previous.content.disposition === ACCEPTED for the new presenter, not the old granted presenter. In local/remote A -> B handoffs, Members.locusMediaSharesUpdate therefore never sees the old A as a granted previous share and never emits endedSharingId or clears A's isContentSharing, leaving the old presenter marked as sharing after B is granted. The accepted handoff path needs to preserve/pass the old granted presenter to the members update, not just the meeting share status.

Useful? React with 👍 / 👎.

…ndoff

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 12406e179a

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

chatgpt-codex-connector · 2026-05-07T02:14:26Z

+        previousContentShare?.disposition === FLOOR_ACTION.GRANTED &&
+        contentShare.disposition === FLOOR_ACTION.ACCEPTED


Preserve handoff state across repeated ACCEPTED deltas

When Locus sends more than one intermediate ACCEPTED update for the same content handoff, the first one preserves the active share, but the next delta has previous.content.disposition === ACCEPTED, so this condition fails and the default branch changes shareStatus to NO_SHARE. A later GRANTED update then again misses the local-unpublish/remote-steal paths that this patch is trying to protect. Consider also preserving while acceptedContentHandoffPreviousShare is already set and the current floor is still ACCEPTED.

Useful? React with 👍 / 👎.

mickelr requested review from a team as code owners May 6, 2026 09:53

mickelr force-pushed the fix/cannot-receive-sharing branch from e10edf7 to 8cb600a Compare May 6, 2026 11:29

mickelr added the validated If the pull request is validated for automation. label May 6, 2026

chatgpt-codex-connector Bot reviewed May 6, 2026

View reviewed changes

mickelr force-pushed the fix/cannot-receive-sharing branch from 8cb600a to e02286e Compare May 6, 2026 12:47

chatgpt-codex-connector Bot reviewed May 6, 2026

View reviewed changes

mickelr force-pushed the fix/cannot-receive-sharing branch 2 times, most recently from e02286e to e956efc Compare May 6, 2026 13:43

chatgpt-codex-connector Bot reviewed May 6, 2026

View reviewed changes

mickelr force-pushed the fix/cannot-receive-sharing branch from e956efc to 05bf5bb Compare May 7, 2026 01:55

chatgpt-codex-connector Bot reviewed May 7, 2026

View reviewed changes

fix(meetings): prevent stale whiteboard share event during content ha…

12406e1

…ndoff

mickelr force-pushed the fix/cannot-receive-sharing branch from 05bf5bb to 12406e1 Compare May 7, 2026 02:11

chatgpt-codex-connector Bot reviewed May 7, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(meetings): prevent stale whiteboard share event during content handoff#4958

fix(meetings): prevent stale whiteboard share event during content handoff#4958
mickelr wants to merge 1 commit into
webex:nextfrom
mickelr:fix/cannot-receive-sharing

mickelr commented May 6, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 6, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 6, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 6, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 7, 2026

Uh oh!

chatgpt-codex-connector Bot left a comment

Uh oh!

chatgpt-codex-connector Bot May 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

		this.shareStatus === SHARE_STATUS.LOCAL_SHARE_ACTIVE &&
		contentShare.disposition === FLOOR_ACTION.ACCEPTED

		previousContentShare?.disposition === FLOOR_ACTION.GRANTED &&
		contentShare.disposition === FLOOR_ACTION.ACCEPTED

Conversation

mickelr commented May 6, 2026

Summary

Why

Test

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 6, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 6, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 6, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 7, 2026

Choose a reason for hiding this comment

Uh oh!

chatgpt-codex-connector Bot left a comment

Choose a reason for hiding this comment

💡 Codex Review

Uh oh!

chatgpt-codex-connector Bot May 7, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant