BUG Calling callObject.stopScreenShare() and callObject.setLocalVideo(false) simultaneously corrupts screen share state

[thomaschanghbw]

Expected behavior

Describe the bug (unexpected behavior)

If I call callObject.stopScreenShare() and callObject.setLocalVideo(false) in immediate succession, I would expect the video and screenVideo tracks to both enter state "off".

When my camera is on and my screenshare is on, and I call the aforementioned methods in immediate succession, the final daily event we receive for the client screensharing is:

tracks: {
audio: {state: 'off', off: {…}, persistentTrack: MediaStreamTrack}
screenAudio: {state: 'off', off: {…}, persistentTrack: null}
screenVideo: {state: 'interrupted', persistentTrack: null}
video: {state: 'off', off: {…}, persistentTrack: undefined}
}

For clients that are not screensharing but are instead subscribed to the screenshare, the tracks object for the screensharing participant is:

tracks: {
audio: {subscribed: true, state: 'off', off: {…}, persistentTrack: MediaStreamTrack}
screenAudio: {subscribed: true, state: 'off', off: {…}, persistentTrack: undefined}
screenVideo: {subscribed: true, state: 'loading', persistentTrack: undefined}
video: {subscribed: true, state: 'off', off: {…}, persistentTrack: undefined}
}

The only ways to recover from this state is:

1. Screensharing participant disconnects and rejoins call
2. Call callObject.startScreenShare(), screenshare, then call callObject.stopScreenShare() (Just calling callObject.stopScreenShare() does not fix the corrupt state)

Steps to reproduce

1. In a Daily call, turn on camera and turn on screenshare
2. Programmatically, call callObject.stopScreenShare() and callObject.setLocalVideo(false) as successive calls
3. Examine the daily participant events sent by daily

System information

• Device: MacBook Pro 14 inch 2021 M1
• OS, version: macOS Monterey 12.0.1
• Browser, version: Chrome Version 100.0.4896.88 (Official Build) (arm64)

[JoseIsra]

why don't you try to wait some miliseconds after the stopScreenShare()

[thomaschanghbw]

Thanks for the suggestion, but in practice we had these events coming in asynchronously and our architecture would require a large-scale refactor to account for this bug.

We are no longer using Daily, so feel free to close this bug report or leave it open for tracking purposes.

[mattieruth]

We did a refactor for how we handle local media. I am not able to reproduce this and so I believe this has been resolved. Feel free to reopen if you find otherwise.