User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

Steps to reproduce:

1. Publish audio only WebRTC stream from Firefox in the example attached
2. Trying to play this stream

Actual results:

Stream is not playing

Expected results:

Stream should be played (in Chrome for example, it's playing)

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Thanks for filing this bug! If you could add the relevant code snippet to the description that would help.

Jan-Ivar, does this sound like a known issue to you?

(In reply to Nico Grunbaum [:ng, @chew:mozilla.org] from comment #2)

Thanks for filing this bug! If you could add the relevant code snippet to the description that would help.

The code sample is in attachment (see Test_connection.zip)
An audio only stream is publishing and playing in Chrome, but is not playing in Firefox

Thanks support for the sample, I can repro with it! Firefox fires a streamless video track event due to offerToReceiveVideo: true for some reason, even though there's nothing to receive. This unexpectedly resets srcObject because e.streams[0] is undefined.

STRs:

1. Open https://jsfiddle.net/jib1/yft3x40q/12/ and share mic.

Expected results:

audio track fired with streams = [object MediaStream]
checking
connected

Actual results:

audio track fired with streams = [object MediaStream]
video track fired with streams =
checking
connected

[Tracking Requested - why for this release]: regression that may cause audio or video to not play on some WebRTC sites.

Regression range: https://phabricator.services.mozilla.com/D64692

tracking+ for 79, but note that we're already out of betas for this cycle and RC week is next week, so only an extremely low-risk fix would be considered for uplift there at this point. Especially since this is an issues we've already been shipping for a few releases.

Maybe we should check GetActive() on mRecvTrack here...

https://searchfox.org/mozilla-central/rev/b2395478c6adf6e5b241be1610fb1d920ed995ed/media/webrtc/signaling/src/peerconnection/RTCRtpReceiver.cpp#522

This is really weird. The same thing doesn't happen when we swap audio/video here.

Found the problem. Running patch through tests now.

Depends on D84206

Try looks ok.

https://hg.mozilla.org/mozilla-central/rev/0d22d5ebae5a
https://hg.mozilla.org/mozilla-central/rev/11ff41f3e95a

Is this something we should consider for ESR78 uplift?

This seems like a good candidate; it is a simple patch.

Comment on attachment 9164798 [details]
Bug 1652426: Fix bug where ontrack was fired for all receivers if a previously processed receiver had a new track. r?mjf

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a really simple web-compat fix.
• User impact if declined:
• Fix Landed on Version: 80
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky):
• String or UUID changes made by this patch: None

Comment on attachment 9164797 [details]
Bug 1652426: Test-case for bug. r?jib

Approved for 78.2esr. Thanks for including a test.

https://hg.mozilla.org/releases/mozilla-esr78/rev/8b3924955fef
https://hg.mozilla.org/releases/mozilla-esr78/rev/5d10e0d8c466

Confirmed issue with 80.0a1 (2020-07-13) on Windows 10.
Verified with 80.0b8.

Verified with 78.2ESR as well.