Closed Bug 1568296 Opened 5 years ago Closed 8 months ago

Support stopping and stopped RTCRtpTransceivers

Categories

(Core :: WebRTC, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
118 Branch
Tracking Status
firefox70 --- wontfix
firefox118 --- fixed

People

(Reporter: jib, Assigned: bwc)

References

(Blocks 3 open bugs)

Details

(Keywords: dev-doc-complete, parity-chrome, parity-edge)

Attachments

(2 files)

Per w3c/webrtc-pc#2220.

This solves the BUNDLE footgun, and in the process deprecates the JS-observable tc.stopped transceiver property in favor of a new "stopped" enum value in tc.direction and tc.currentDirection.

Firefox will likely continue to expose the stopped property for a release or two for backwards compatibility until we have telemetry numbers for it that justify deprecating it.

This is largely updated already in documentation, but there is some review to do, and IIRC I held off pulling the trigger on a few bits until it actually hit the spec proper. We may need to review some examples throughout content to change this.

On a related note, but not part of this work: we should review our documentation to start shifting some of it from using addTrack() to working with transceivers directly, as this is the new hotness.

Keywords: dev-doc-needed

Bugbug thinks this bug is a enhancement, but please change it back in case of error.

Type: defect → enhancement

Byron and I agreed it makes sense to tackle https://github.com/w3c/webrtc-pc/pull/2160/files as well, as part of this work. That is: remove stopped transceivers from pc.getTransceivers() in SRD(offer).

Blocks: 1505509

Docs team: will not ship in 70.

Summary: Support stopping and stopped transceivers → Support stopping and stopped RTCRtpTransceivers
Severity: normal → S3

Safari does not implement this yet. We have other web-compat bugs that are more of a parity problem than this right now.

Priority: P2 → P3
Assignee: jib → docfaraday

Marking this as dependent on bug 1813468, since it is cleaning up a lot of the same code.

Depends on: 1813468

mochitest/crashtest/gtest look fine. Pathless wpt try push to work around bug 1830520:

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

Attachment #9328179 - Attachment description: Bug 1568296: Test cases for bug. r?jib → Bug 1568296: Test cases for RTCRtpTransceiver.[[Stopping]]. r?jib

Try looks fine.

Pushed by bcampen@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/c1679789476d
Test cases for RTCRtpTransceiver.[[Stopping]]. r=jib
https://hg.mozilla.org/integration/autoland/rev/b5bb91755232
Implement "stopping" state for RTCRtpTransceiver. r=jib,mjf,webidl,smaug
https://hg.mozilla.org/integration/autoland/rev/39c307008548
apply code formatting via Lando
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/41387 for changes under testing/web-platform/tests
Upstream PR merged by moz-wptsync-bot

MDN docs work for this can be tracked in https://github.com/mdn/content/issues/28845

Above it is indicated that RTCPeerConnection.getTransceivers() was also updated to remove transceivers that are stopped.

  • Did that happen too in this update?
  • Is there a test in wpt I can use to verify other browsers have made this change too?

Thank you.

Flags: needinfo?(docfaraday)

I don't think that happened in this update, I think that's been the case for some time.

I see a wpt here: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/webrtc/RTCRtpTransceiver-stop.html#119-137

Flags: needinfo?(docfaraday)

I don't think that happened in this update, I think that's been the case for some time.

Thanks @Byron. FYI It did happen in 118 that we started passing this test according to browserstack.

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

Attachment

General

Created:
Updated:
Size: