Bug 281758 – REGRESSION (Safari 18): Audio from disabled MediaStreamTrack is published

• Component: WebRTC
• Status: RESOLVED FIXED

Created attachment 472987 [details]
A screen capture demonstrating Safari 18 publishing the audio from a disabled MediaStreamTrack

## Description
I built a WebRTC application that has a "Lobby" experience wherein users are allowed to change hardware/apply effects/disable devices prior to entering the video room. In Safari 18 disabling the mic prior to connecting to the video room results in everyone else in the room being able to hear you. This was not an issue in Safari 17 and is not an issue in Chrome.

Please watch the attached screen capture. I demonstrate that Safari knows the MediaStreamTrack is disabled and still publishes its audio.

## Which platforms are impacted?
Desktop Safari 18 and all iOS browsers on iOS 18.

## Technical Details
When my application loads, I acquire the user's camera and mic. If the user disables their camera, I release the hardware with MediaStreamTrack.stop(). If the user disables their mic, I do not release their hardware but instead set the MediaStreamTrack's enabled property to false. This stops sending audio to other participants.

In Safari 18, I have confirmed that both prior to connecting to the video room and immediately after connecting to the video room, the user's mic MediaStreamTrack.enabled value is false. However, despite being false, all other participants can hear the Safari 18 user.

## Expected Results
When publishing a disabled MediaStreamTrack, Safari should not publish bytes from that track.

## Temporary Mitigation
I noticed that impacted users who manually enable then disable their microphone after connecting to the video room end up with the desired result - their mic no longer transmits audio. With that in mind, I'm currently putting a mitigation approach through our QA process. The solution checks a user's mic MediaStreamTrack.enabled value immediately after connecting to the video room. If the mic's enabled state is false, I toggle the enabled state to true then false. This currently appears to fix the issue, though it has not yet reached out production environment.

Note - I'm using twilio-video (https://github.com/twilio/twilio-video.js/). But they haven't cut a release since October 3, 2023 so it's extremely unlikely this is related to a twilio-video change.

[Radar WebKit Bug Importer]

<rdar://problem/138321310>

[youenn fablet]

Is there a way to get access to the repro website, or getting repro steps?

Hi, I'd be happy to provide a URL where you can reproduce the issue. I don't want to share the URL publicly. Are you able to email me at the address that shows in this issue? If you can email me from an email address that clearly demonstrates you work for Apple/Webkit, I'd be happy to pass along the URL.

[EWS]

Committed 285916@main (c29f5f0e0f7e): <https://commits.webkit.org/285916@main>

Reviewed commits have been landed. Closing PR #35935 and removing active labels.

[youenn fablet]

*** Bug 282465 has been marked as a duplicate of this bug. ***

[EWS]

Committed 283286.457@safari-7620-branch (0d54f9deb9a2): <https://commits.webkit.org/283286.457@safari-7620-branch>

Reviewed commits have been landed. Closing PR #2243 and removing active labels.