Support stopping and stopped RTCRtpTransceivers
Categories
(Core :: WebRTC, enhancement, P3)
Tracking
()
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.
Comment 1•4 years ago
•
|
||
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.
Comment 2•4 years ago
|
||
Bugbug thinks this bug is a enhancement, but please change it back in case of error.
Reporter | ||
Comment 3•4 years ago
|
||
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).
Comment 4•4 years ago
|
||
Docs team: will not ship in 70.
Assignee | ||
Updated•2 years ago
|
Updated•1 year ago
|
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 5•1 year ago
|
||
Safari does not implement this yet. We have other web-compat bugs that are more of a parity problem than this right now.
Assignee | ||
Updated•10 months ago
|
Assignee | ||
Comment 6•10 months ago
|
||
Marking this as dependent on bug 1813468, since it is cleaning up a lot of the same code.
Assignee | ||
Comment 7•8 months ago
|
||
Assignee | ||
Comment 8•8 months ago
|
||
Assignee | ||
Comment 9•8 months ago
|
||
Depends on D175260
Assignee | ||
Comment 10•7 months ago
|
||
Assignee | ||
Comment 11•7 months ago
|
||
mochitest/crashtest/gtest look fine. Pathless wpt try push to work around bug 1830520:
https://treeherder.mozilla.org/jobs?repo=try&revision=a8e26a1abfe1ed1e98634baf9d834a812a7d9f4c
Assignee | ||
Comment 12•4 months ago
|
||
Updated•4 months ago
|
Assignee | ||
Comment 13•4 months ago
|
||
Try looks fine.
Comment 14•4 months ago
|
||
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
Comment 16•4 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/c1679789476d
https://hg.mozilla.org/mozilla-central/rev/b5bb91755232
https://hg.mozilla.org/mozilla-central/rev/39c307008548
Upstream PR merged by moz-wptsync-bot
Updated•4 months ago
|
Comment 18•3 months ago
•
|
||
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.
Assignee | ||
Comment 19•3 months ago
|
||
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
Comment 20•3 months ago
|
||
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.
Updated•3 months ago
|
Description
•