July 1, 2019
As of Firefox 68—releasing next week—camera and microphone will require an
https connection to work. Access from insecure
http will cease to work, matching how Chrome works. Camera and microhone are powerful features, and Firefox will now only expose them in secure contexts, a security and privacy improvement.
Largely an issue for developers to catch up on, this may nonetheless affect end users who follow old
http links to servers that either still don’t redirect their users to
https automatically, or don’t support it at all. If you’re experiencing this problem, click your URL bar, and if the URL starts with
http, try changing it to
https, and it should work again, provided the server supports https.
The rest of this blog post is for web developers, since there are some details that may be of interest to them. Firefox is deprecating camera and microphone access in insecure contexts in two steps: (more…)
April 7, 2019
New preface: What if you could add and remove media to and from a live WebRTC connection, without having to worry about state, glare (signaling collisions), role (what side you’re on), or what condition the connection is in? You’d simply call
pc.addTrack(track, stream) regardless of time and place, and your track would just show up on the opposite side, without risk of terminal connection failure. A pipe dream? Too much to ask? Actually, now that Chrome has finally fixed its
negotiationneeded event, this almost works! But you’re not using it, because “almost” doesn’t cut it. It only works 95% of the time, and the stakes from glare are too high in Chrome (no way to roll back from it, just
pc.close()). But this original promise of the API is still within reach. We just need browsers other than Firefox to implement rollback, and fix some glaring (no pun intended) races in a few methods in the specification.
Perhaps few things in the WebRTC API cause as many pilot errors as the asymmetric exchange of SDP and ICE. Its stateful
signalingState and timing sensitive ICE trickling can be a source of races if programmed incorrectly. As if that’s not challenging enough, keeping the two sides in sync and the two directions apart throws a lot of people for a loop (more puns).
What if I told you we can tame this complexity? That the manual way most people go about negotiating in WebRTC today is inferior, and possibly racy?
I’m talking about
December 5, 2018
"rollback". Two mechanisms that can be used in concert to abstract negotiation away entirely. Yet, no-one is using them, because they haven’t worked, and don’t work yet in Chrome, respectively. We’ll introduce both. (more…)
Update: We’ve pushed this back to Firefox 66, giving you a little more time!
Please go to isRemote in getStats() will disappear in Firefox 66.
August 6, 2018
Are you using
getStats() for remote statistics in Firefox? Look for this warning today in Firefox Nightly (63, not 66):
⚠ Detected soon-to-break getStats() use! stat.isRemote goes away in Firefox 66, but won’t warn there!
TL;DR: If you see this warning in web console, read on to act now. Firefox 66 will move remote stats to
isRemote will disappear, to comply with a change to the spec.
Firefox 63-65 will warn about this, but for technical reasons Firefox 66 will not be able to. This is because once the stats move in 66, there’s really no way to detect that you intended to look for remote stats the old way.
Update: The original article said Firefox 55. We’ve pushed it back to Firefox 66, giving you a little more time!
July 12, 2018
If you ever had a meeting over video and wanted to present some slides, there is a high chance you have used screen-sharing to do so. The WebRTC specification recently converged on a standard way to accomplish this. It took a fairly long time, because the security considerations for a web page accessing the pixels of your entire screen or another window are quite serious.
Browsers are actively implementing the standard
getDisplayMedia API now, with Microsoft Edge being the first to ship a native implementation. You can track the current implementation status for Firefox, Chrome, Microsoft Edge and Safari.
Both Chrome and Firefox have long supported screen-sharing using slightly different and non-standard APIs. A couple of weeks back, Harald Alvestrand at Google asked whether it was possible to polyfill
navigator.mediaDevices.getDisplayMedia for screen-sharing in adapter.js.
Update 11/17/18: getDisplayMedia used to live on
navigator but was recently moved to
navigator.mediaDevices.getDisplayMedia. Examples and adapter.js have been updated to match.
July 2, 2018
All the browser with support for negotiating data channels via SDP are using the same format. But the format is based on a specification from 2013. Since the specification has changed a lot since then it’s time to update the implementations to meet the latest spec.
If you are negotiating a data channel today in Firefox 61 (or current Chrome release) the SDP will looks something this:
July 2, 2018
Debugging WebRTC? Ever wanted a bit more visibility into the flow of a WebRTC call? Or see exactly what PeerConnection API calls were made and when? Have we got a debugging deal (dev tools plugin) for you! Go here or search for “dev tools media panel” on about:addons.
After loading the plugin and starting a call on, for example, appear.in, open the dev tools (Tools -> Web Developer -> Toggle Tools). Next, click on the “Media-Webrtc” pane. The “Media-Webrtc” pane is most likely at the far right. Finally, selecting the Webrtc tab shows something like:
May 22, 2018
After extensive work from the Google Hangouts team and the Firefox WebRTC team both, the consumer version Google Hangouts and the enterprise version Google Meet, are working in Firefox with no plugin required thanks to WebRTC!
How we got here
Turning off the NPAPI support in Firefox 53 resulted in the Google Hangouts plugin not working anymore. Unfortunately that meant that Firefox users could no longer enjoy Google Hangouts or Meet.
Google Chrome users could continue to use Hangouts and Meet without a NPAPI plugin, because the Google Hangout backend service had support for a flavor of WebRTC only implemented in Google Chrome. But that version was not spec compliant and was thus never supported by Firefox.
It took a considerable amount of effort from the Google Hangouts team to update their backend service to the latest version of the WebRTC specs to support Firefox. At the same time the Firefox WebRTC team implemented a bunch of features to support large scale conferencing for Google Meet.
In fact Google Hangouts, the consumer version, started working with Firefox 56. Now with Firefox 60 we were able to ship all the required features to also support Google Meet.
Thanks to all the hard working people involved in this project and resulting in making the Open Web a better and safer place from today on!
May 9, 2018
On a web conference call, have you ever wondered if people can see you? Maybe you’ve tried to decipher the site’s video-mute button, often some red camera symbol with a slash through it—“Is it on or off? Does red mean stop or live? Is the slash telling me I’m muted now, or to click here to mute?”—All the while the camera light at the top of your laptop keeps glaring at you brightly.
We have fixed this in Firefox 60.
We can’t fix the websites, but in Firefox 60, whenever you video-mute, your laptop or USB camera hardware light will now extinguish. Whenever you unmute again, it will light back up. No more worrying if you’re live! (more…)
April 4, 2018
Firefox now implements the RTCRtpTransceiver API, a.k.a. stage 3 in my blog post “The evolution of WebRTC 1.0.” from last year. Transceivers more accurately reflect the SDP-rooted network behaviors of an RTCPeerConnection. E.g.
addTrack) now creates a receiver at the same time, which correlates better with the bi-directional m-line that begins life in the SDP offer, rather than being something that arrives later once negotiation completes. This lets media arrive early on renegotiation.
But most WebRTC sites today are still written the old way, and there are subtle differences to trip over. Web developers are stuck in a bit of limbo, as other browsers haven’t caught up yet. In light of that, we should probably dive right into two immediate breaking spec changes you might have run into in Firefox 59:
- Remote tracks are now muted and temporarily removed from their stream(s), rather than ended, in response to direction changes (e.g. from the poorly named
track.ids at the two end-points rarely correlate anymore.
Importantly, this affects you whether you use transceivers or not.
addStream) is just a tweaked version of
addTransceiver these days. This blog will look at how to handle this—tying up lose ends from last year’s blog post—and demonstrate how Firefox works. (more…)