It doesn't look like we mention that these are available in the first place. Almost pointless to add them considering they are now being removed, but hey ;-)

Do you think we're ready to remove this stuff? webrtc-landing still uses some of this:

https://mozilla.github.io/webrtc-landing/data_test.html
https://mozilla.github.io/webrtc-landing/data_latency_test.html
https://mozilla.github.io/webrtc-landing/canvas_demo.html
https://mozilla.github.io/webrtc-landing/canvas_filter_demo.html

I'd like to say yes—with the exception of navigator.mozGetUserMedia (see bug 1279936)—but from bug 1155923 comment 5 I'm not sure. That was 4 years ago, but unfortunately we don't have telemetry on this.

The safe way to go about it might be to gather telemetry on mozRTCPeerConnection usage first, to know what breakage to expect.

That said, even having a telemetry number on mozRTCPeerConnection usage would not tell us about breakage, because it wouldn't distinguish

var RTCPeerConnection = window.webkitRTCPeerConnection || window.mozRTCPeerConnection || window.RTCPeerConnection; // OK!

from

var RTCPeerConnection = window.webkitRTCPeerConnection || window.mozRTCPeerConnection; // Would break!

I don't see a way to detect actual breakage numbers. That said, a ballpark mozRTCPeerConnection usage number would be instructive if it's really low.

Nico, is this something we could add to bug 1528078 which you'd expressed interest in tackling?

Yes, I will be tackling it in bug 1528078.

Turns out we do have telemetry probe for this: 2.7% of peer connections use moz-prefix. Breakage may be even lower based on comment 3.

• 0.218% of pageloads called any of the moz-prefixed peer connection methods
• 8% of pageloads call the non-deprecated RTCPeerConnection constructor (from chromestats, since we don't have counters for that)

Taking this; it is about time, and low-hanging fruit.

Depends on D168415

https://treeherder.mozilla.org/jobs?repo=try&revision=3cd05f17a7fc08fae22df095f70fd1be79d44edd
https://treeherder.mozilla.org/jobs?repo=try&revision=3fd07279480f4929f595fd756f34c0969bb103a3

Try looks fine.

Need to make a pull request here to get rid of this mozRTC stuff:

https://github.com/mozilla/webrtc-landing

See https://github.com/mozilla/webrtc-landing/pull/35

Backed out for causing build bustages on PeerConnectionImpl.cpp

• Backout link
• Push with failures
• Failure Log
• Failure line: /builds/worker/checkouts/gecko/dom/media/webrtc/jsapi/PeerConnectionImpl.cpp:2024:38: error: unused variable 'id' [-Werror=unused-variable]

mochitest log: https://treeherder.mozilla.org/logviewer?job_id=405685822&repo=autoland

Backed out for causing wpt failures in

Backout link: https://hg.mozilla.org/integration/autoland/rev/19e0bc283894a3bf801c7edb6c73879c3aeec836

Push with failures

Failure log #1 | TEST-UNEXPECTED-TIMEOUT | /webrtc/RTCPeerConnection-remote-track-mute.https.html | pc.close() on one side causes mute events on the other - Test timed out

Failure log #2 | TEST-FAIL | /webrtc/RTCPeerConnection-getStats.https.html | getStats() audio and video validate all mandatory stats - assert_equals: Expect dictionary.transportId to be string expected "string" but got "undefined"

Failure log #3 | TEST-UNEXPECTED-FAIL | /webrtc/RTCPeerConnection-getStats.https.html | getStats() on track associated with RTCRtpReceiver should return stats report containing inbound-rtp stats - assert_unreached: required stats <...>

https://hg.mozilla.org/mozilla-central/rev/e8e892e3e742

Release Note Request (optional, but appreciated)
[Why is this notable]:
Sadly, there are still services that are using this.
[Affects Firefox for Android]:
Yes.
[Suggested wording]:
Removed the long-deprecated mozRTCPeerConnection, mozRTCIceCandidate, and mozRTCSessionDescription types.
[Links (documentation, blog post, etc)]:

Added to the Fx113 Nightly relnotes. I added an additional line saying that sites should use the non-prefixed variants instead.

FYI MDN docs work for this can be tracked in https://github.com/mdn/content/issues/26146. There wasn't much to do in this case other than a release note mentioning the removal.