1652426 - Firefox fails to play audio (because offerToReceive causes local track event when there's nothing to receive)

Status: VERIFIED FIXED

(Core :: WebRTC: Audio/Video, defect, P2)

Description

[support]

Attachment: Test_connection.zip

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)

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 2

[Nico Grunbaum [:ng, @chew:mozilla.org]]

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

Comment 3

[Nico Grunbaum [:ng, @chew:mozilla.org]]

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

Comment 4

[support]

(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

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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

Comment 6

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

[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

Comment 7

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 8

[Byron Campen [:bwc]]

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

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

Comment 9

[Byron Campen [:bwc]]

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

Comment 10

[Byron Campen [:bwc]]

Found the problem. Running patch through tests now.

Comment 11

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a14e5d9d6080b53b290a173af1297addf7a49140

Comment 12

[Byron Campen [:bwc]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3e20b7667bc7a8594036645d784af1c73bfd0d22

Comment 13

[Byron Campen [:bwc]]

Attachment: Bug 1652426: Test-case for bug. r?jib

Comment 14

[Byron Campen [:bwc]]

Attachment: Bug 1652426: Fix bug where ontrack was fired for all receivers if a previously processed receiver had a new track. r?mjf

Depends on D84206

Comment 15

[Byron Campen [:bwc]]

Try looks ok.

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0d22d5ebae5a
Test-case for bug. r=jib
https://hg.mozilla.org/integration/autoland/rev/11ff41f3e95a
Fix bug where ontrack was fired for all receivers if a previously processed receiver had a new track. r=mjf

Comment 17

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/24695 for changes under testing/web-platform/tests

Comment 18

[Atila Butkovits]

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

Comment 19

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 20

[Ryan VanderMeulen [:RyanVM]]

Is this something we should consider for ESR78 uplift?

Comment 21

[Byron Campen [:bwc]]

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

Comment 22

[Byron Campen [:bwc]]

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 23

[Ryan VanderMeulen [:RyanVM]]

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

Approved for 78.2esr. Thanks for including a test.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

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

Comment 25

[Cristian Fogel [:cfogel]]

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

Comment 26

[Cristian Fogel [:cfogel]]

Verified with 78.2ESR as well.