Conversation
| return new Promise(function(resolve, reject) { | ||
| reject("getUserMedia is not supported in this browser."); | ||
| if (!(window.RTCPeerConnection || window.webkitRTCPeerConnection || window.mozRTCPeerConnection || window.RTCIceGatherer)) { | ||
| var e = new Error("getUserMedia is not supported in this browser."); |
There was a problem hiding this comment.
I don't think this text was ever getting seen. In fact, I think that we were returning this for SSL errors and accidentally correctly reporting them to the user as such.
|
|
||
| var rtc = (function() { | ||
| var isActive = false; | ||
| var isSupported = true; |
There was a problem hiding this comment.
There's a TODO to remove it (see below) and it's always set to true.
| padcookie.setPref("rtcEnabled", true); | ||
| self.getUserMedia(); | ||
| } else { | ||
| self.showNotSupported(); |
There was a problem hiding this comment.
Unless isSupported is getting set somewhere outside of this module, this function wasn't getting called.
|
Oh yeah, I also rebased |
|
Oh, and according to the doc, even earlier versions of WebRTC used |
| if (!(window.RTCPeerConnection || window.webkitRTCPeerConnection || window.mozRTCPeerConnection || window.RTCIceGatherer)) { | ||
| var e = new Error("getUserMedia is not supported in this browser."); | ||
| // I'd use NotSupportedError but I'm afraid they'll change the spec on us again | ||
| e.name = 'CustomNotSupportedError'; |
There was a problem hiding this comment.
Best option I could think of at the time, but I'm open to other things. Perhaps just a better name.
Overview
The Most Interesting Part
So here's a couple very fun facts:
NotAllowedErrorwould mean either that the user disallowed access to the camera/mic, or the connection was insecure. As such, the only way I can think of distinguishing them is by checking forhttps(as we sortof were before I "fixed" it in a previous PR)NotAllowedErrorthankfully only means that the user disallowed access to the camera/mic. However, insecure connections are instead handled by hidingnavigator.mediaDevices,navigator.getUserMedia, and possibly other things. The absence of those things used to be our way of testing for outdated browsers. So now, we need a way to distinguish between insecure and outdated, and the best way I can think of is to check for the existence of some other fields.So we had to handle all that. The polyfill was already handling missing
getUserMediaas an "unsupported" error, so I changed it to distinguish between the "unsupported" and "insecure" errors and return accordingly. I let the function that callsgetUserMediacontinue to handle all errors by giving an appropriate user message, but now I include the two potentially returned by the polyfill and I disambiguateNotAllowedError.Question
As a separate matter, I wonder whether
getUserMediaPolyfillis technically a polyfill anymore. By definition it looks like they're supposed to make older browsers behave like newer ones. Here, I'm making newer browsers behave like older ones, because it's just easier to handle errors this way. So the options I can think of: