Twilio-video.js: Foregrounding Safari tab after ending local tracks restarts camera / microphone.

[rpdobson123]

• [X] I have verified that the issue occurs with the latest twilio-video.js release and is not marked as a known issue in the CHANGELOG.md.
• [X] I reviewed the Common Issues and open GitHub issues and verified that this report represents a potentially new issue.
• [X] I verified that the Quickstart application works in my environment.
• [X] I am not sharing any Personally Identifiable Information (PII)
  or sensitive account information (API keys, credentials, etc.) when reporting this issue.

Code to reproduce the issue:

// when creating local tracks
const localTracks = await createLocalTracks({
    video: { ...videoTrackOptions,deviceId: { exact: intendedVideoDevice.deviceId } },
    audio: { deviceId: { exact: intendedAudioDevice.deviceId } },
});

// when ending local tracks
const localTracks [...this.props.twilioRoom.localParticipant.tracks.values()]
localTracks.forEach(localTrack => {
    localTrack.stop();
    this.props.twilioRoom.localParticipant.unpublishTrack(localTrack);
})

repro steps:

In safari on MacOS Big Sur:

1. Join call (starting tracks)
2. End call (ending tracks)
3. Continue browsing the site
4. Change to a second tab
5. Change back to the first tab

Expected behavior:
The camera is off

Actual behavior:
_reacquiretracks executes, re-enabling the webcam.
I am suspicious it may be related to this change:
https://github.com/twilio/twilio-video.js/commit/5933fb05f8174192c8c6d780ab4577f0e92c3fe3

The camera should no longer be in use in this instance as it's been unpublished, but foregrounding safari causes it to be revived, which is undesired.

Software versions:

• [x] Browser(s): Safari
• [x] Operating System: MacOS Big Sur
• [x] twilio-video.js: 2.10
• [x] Third-party libraries (e.g., Angular, React, etc.): React, Typescript, Less

[rpdobson123]

I believe this function is the offender:

  function shouldReacquireTrack() {
    const { _workaroundWebKitBug1208516Cleanup, isStopped, mediaStreamTrack: { muted } } = localMediaTrack;
    const isInadvertentlyStopped = isStopped && !!_workaroundWebKitBug1208516Cleanup;
    return document.visibilityState === 'visible' && (muted || isInadvertentlyStopped) && !trackChangeInProgress;
  }

If the track was stopped intentionally, could we flag it as such so it doesn't become re-started in this way?

[manjeshbhargav]

Hi @rpdobson123 ,

Thanks for reporting this issue. We will investigate and do what's needed. Please watch this space for updates.

[makarandp0]

Thanks @rpdobson123, We are tracking this internally now. One quick question, You mentioned it repros on Big Sur -Did it repro on older MacOs (Catalina) as well? (JSDK-3100)

[rpdobson123]

@makarandp0 - I have not personally reproduced it outside of Big Sur. I'm asking our QA team to see if any of them are running Big Sur. Thanks for the response!

Edit - no Catalina as far as I can tell

[rpdobson123]

@manjeshbhargav any updates on this? We're implementing twilio as part of a single page application and we currently have to force refresh safari users to be certain not to leave their camera on while they use the rest of the site.

[makarandp0]

Hello @rpdobson123, we are still investigating this - but in the meanwhile to workaround this issue, can you try to specify
workaroundWebKitBug1208516: false when creating tracks on Big Sur, and check if that helps ?

something like:

 const  = {
    video: { ...videoTrackOptions,deviceId: { exact: intendedVideoDevice.deviceId }, workaroundWebKitBug1208516: false },
    audio: { deviceId: { exact: intendedAudioDevice.deviceId }, workaroundWebKitBug1208516: false },
}

const localTracks = await createLocalTracks(localTrackOptions);  

Thanks,
Makarand

[rpdobson123]

@makarandp0 - adding that attribute fixed the issue!!

If it's any help, the original bug with workaroundWebKitBug1208516 - video tracks being stopped when tabbing out on safari - doesn't seem to be affecting us after applying your change. I'm curious if your team or Safari might have made the workaround obsolete.

Thanks a ton! This is a huge weight off my team's shoulders knowing this isn't an implementation bug.

[makarandp0]

@rpdobson123 - I am glad that the suggestion helped.

The original webkit issue affects safari on iOS. I would suggest you pass workaroundWebKitBug1208516: false only for desktop safari.

I will close this ticket now, but will keep tracking it internally (JSDK-3100) for resolving it for Big Sur.
Thanks,
Makarand.