Closed Bug 1652426 Opened 10 months ago Closed 10 months ago

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

Categories

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

78 Branch
defect

Tracking

()

VERIFIED FIXED
mozilla80
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 80+ verified
firefox78 - wontfix
firefox79 + wontfix
firefox80 + verified

People

(Reporter: support, Assigned: bwc)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Attached file 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)

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

Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core

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

Flags: needinfo?(support)

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

Flags: needinfo?(jib)

(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

Flags: needinfo?(support)

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
Assignee: nobody → docfaraday
Severity: -- → S3
Flags: needinfo?(jib) → needinfo?(docfaraday)
Priority: -- → P2
Summary: Audio only WebRTC stream does not play if video playback requested by constraints → offerToReceive causes local track event even though there's nothing to receive

[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

Status: UNCONFIRMED → NEW
Has Regression Range: --- → yes
Has STR: --- → yes
Ever confirmed: true
Keywords: regression
OS: Unspecified → All
Regressed by: 1616875
Hardware: Unspecified → All
Summary: offerToReceive causes local track event even though there's nothing to receive → Firefox fails to play audio (because offerToReceive causes local track event when there's nothing to receive)

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.

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

Found the problem. Running patch through tests now.

Try looks ok.

Pushed by bcampen@mozilla.com:
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
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/24695 for changes under testing/web-platform/tests
Status: NEW → RESOLVED
Closed: 10 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla80
Upstream PR merged by moz-wptsync-bot
Flags: qe-verify+

Is this something we should consider for ESR78 uplift?

Flags: needinfo?(docfaraday)
Flags: in-testsuite+

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

Flags: needinfo?(docfaraday)

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
Attachment #9164798 - Flags: approval-mozilla-esr78?
Attachment #9164797 - Flags: approval-mozilla-esr78?

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

Approved for 78.2esr. Thanks for including a test.

Attachment #9164797 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+
Attachment #9164798 - Flags: approval-mozilla-esr78? → approval-mozilla-esr78+

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

Status: RESOLVED → VERIFIED
Flags: qe-verify+

Verified with 78.2ESR as well.

You need to log in before you can comment on or make changes to this bug.