fix(base/tracks): prevent crash when starting screenshare with audio and null local audio

[AmoghParmar]

Fixes #16846

This pull request resolves a critical runtime error (TypeError: Cannot read properties of null (reading 'setEffect')) that occurs when a user initiates screen sharing with audio while their local microphone is blocked or disconnected.

Previously, the application would crash because it attempted to apply an audio mixer effect to a null local audio track. This change implements proper null safety and improves WebRTC track handling by falling back to addTrack() when no existing transceiver is found.

Testing done

Manual verification was performed on a local development environment to ensure stability.

Manual testing steps:

• Launched Jitsi Meet locally.
• Blocked microphone permissions in the browser to force a null local audio state.
• Initiated Screen Sharing with the "Share Tab Audio" option enabled.
• Verified that the "Uncaught runtime errors" red screen no longer appears.
• Joined meeting with another participant.
• Started screen share with audio enabled.
• Changed microphone during screen share.
• Verified that "Replace track failed - no transceiver" error no longer appears.

Verified:

• The application correctly triggers conference.addTrack() instead of replaceTrack(null, ...).
• Screen sharing starts successfully without crashing the session.

Screenshots (UI changes only)

Before

After

Proposed changelog entries

• fix(base/tracks): prevent crash during screen sharing when microphone is disabled or changed.

Files changed

• actions.web.ts - null guard on localAudio before calling setEffect()
• actions.any.ts - handle null oldTrack in replaceLocalTrack by using addTrack instead of replaceTrack

Proposed changelog category

/label bug, base/tracks

Submitter checklist

• The issue Microphone error and shows muted when changing during screen share #16846 is well-described and linked.
• The commit follows the mandatory fix(base/tracks) scope.
• The branch has been rebased onto the latest master (No merge commits).
• Manual testing has been performed as described above.
• npm run lint was executed and passed with no errors.

Desired reviewers

@saghul @jallamsetty1

[jitsi-jenkins]

Hi, thanks for your contribution!
If you haven't already done so, could you please make sure you sign our CLA (https://jitsi.org/icla for individuals and https://jitsi.org/ccla for corporations)? We would unfortunately be unable to merge your patch unless we have that piece :(.

[AmoghParmar]

Hi, thanks for your contribution! If you haven't already done so, could you please make sure you sign our CLA (https://jitsi.org/icla for individuals and https://jitsi.org/ccla for corporations)? We would unfortunately be unable to merge your patch unless we have that piece :(.

Hi! I have signed and submitted the ICLA as an individual contributor today (Feb 23, 2026). Looking forward to the review! Thanks.

[jallamsetty1]

Why is this hasAudioTrack check needed here? The else block will be executed only when localAudio doesn't exist. Also, addTrack internally calls replaceTrack so using one or the other doesn't make any difference.

[AmoghParmar]

Thanks for the review! You were right, I've simplified the else block by removing the redundant hasAudioTrack check and unnecessary replaceTrack(null, ...) call.
I've also addressed the root cause in actions.any.ts. When replaceLocalTrack is called with oldTrack = null during mic change while screen sharing, it now calls conference.addTrack(newTrack) instead of conference.replaceTrack(null, newTrack) to avoid the "no transceiver for old: null" error.

[jallamsetty1]

Can you let me know the steps to reproduce the "no transceiver for old: null" error. The library should handle this case when replaceTrack is called with oldTrack=null. I am not reproducing any of these issues.

[AmoghParmar]

Helloo @jallamsetty1, to reproduce this issue:

1. Firstly we need to create a meeting with another participant.
2. After that we need to block microphone permissions from the browser settings.
3. Then, Start screen sharing with "Share Tab Audio" enabled.

This triggers the error. I was able to reproduce this on Linux (not just Windows as mentioned in the original issue #16846).

If the library already handles the oldTrack = null case internally, I can revert the actions.any.ts change and keep only the actions.web.ts null guard fix. Please let me know!

[jallamsetty1]

Nope, I am not able to reproduce the issue using the above steps. Audio share works as expected even when the users microphone permissions are revoked mid call. Are you able to attach a video showing how you are reproducing it?

[AmoghParmar]

Hello @jallamsetty1, I was able to reproduce the issue.
Please find the attached screen recording below.

Steps followed:

1. Created a new test meeting
2. Copied the link and opened in another browser as another participant
3. From the moderator window, shared the entire screen with "Share Tab Audio" enabled

Error appears: "Replace track failed - no transceiver for old: null"

Reproduced on: Linux (Chrome)

JITSI-error.webm

Could you please confirm if this reproduction is valid? Should I keep both actions.web.ts and actions.any.ts fixes, or revert actions.any.ts?