STR: open a hello.firefox.com link created by someone else or in another browser/profile, with one participant already in it; click “Join The Conversation”. Expected: chat happens. Actual: gets stuck with progress indicator spinning, no video in self-view area. There's a message in the browser console about NS_ERROR_FAILURE at PeerConnection.js line 373, but nothing more informative than that. This is the Mac Nightly dated 2015-02-24; the same Hello URL worked on the same hardware in Chrome 40.0.2214.111.

Hi Jed -- Thanks for reporting this. Is this repeatable? Have you had successful Hello calls on your machine with previous versions of Firefox? Does Firefox Beta (Fx 37) work for you? And release (Fx36)? If this is repeatable, can you turn on logging? (See https://wiki.mozilla.org/Media/WebRTC/Logging for instructions on how to do that.) And post the logs here? Thanks.

Repeatable, but not with Aurora/Beta/Release. I'm going to see if I can reproduce it with a local build so I can bisect.

Oh wait. I know what's different here: e10s. It works in a non-e10s window in the same Nightly where it doesn't work normally.

Line 373 is the c++ code failing to initialize PeerConnection. [1] I'm not able to reproduce on a trunk from 2015-02-24. Logs would be good. [1] http://mxr.mozilla.org/mozilla-central/source/dom/media/PeerConnection.js?rev=0cbedfe1417d#373

Hey Jed, Thanks for noticing this is e10s-related. Typically Hello works under e10s. Is it possible you have something else enabled (like forcing Nightly to use H.264 for WebRTC calls by default)?

I'm able to reproduce this problem on my Mac with the public Nightly 39.0a1 (2015-02-24) and e10s turned on. The one thing which I noticed is different: in the above scenario I only get a permission prompt for mic only! That obviously explains why there are problems with the video in this case.

I this on the browser console: RTCIceServer.url is deprecated! Use urls instead. <unknown> NS_ERROR_FAILURE: PeerConnection.js:373:0 TypeError: pc is undefined sdk.js:10757:2 Not sure if the IceServer url warning is related. Theoretically it should not, but might be worth mentioning it here.

The deprecation warning is harmless.

(In reply to Nils Ohlmeier [:drno] from comment #6) > The one thing which I noticed is different: in the above scenario I only get > a permission prompt for mic only! > That obviously explains why there are problems with the video in this case. That was also happening here, but I didn't notice it as out of the ordinary until I saw this comment.

Today I no longer get the NS_ERROR_FAILURE, but I still only get a prompt for mic only. Interestingly my logging for the gUM constraints tells me that audio and video got requested via the constraints...

The same problem exists with pretty much any WebRTC service: apprtc, talky.io,... they all only show a door hanger for audio, even though their code requests audio and video.

Anything with NSPR_LOG_MODULES=MediaManager:5 ?

So with MediaManager:9,GetUserMedia:9 I see the following in the logs: 2015-02-26 01:10:15.298049 UTC - 332414976[11aa7c670]: VoEHardware:GetRecordingDeviceName: Failed 9013 Which apparently translates into: #define VE_CANNOT_RETRIEVE_DEVICE_NAME 9013 The fun thing is that by the time that error appears in my logs this call: https://dxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.cpp#1356 has returned already with a zero length result and therefore it appears as if my system does not have a camera.

Sorry that error message apparently is miss-leading as it gets generated by EnumerateAudioDevices().

The problem as far as I have tracked it is that I'm hitting this line here: https://dxr.mozilla.org/mozilla-central/source/dom/media/webrtc/MediaEngineWebRTC.cpp#221

I can't reproduce. Can you try mozregression? I suspect Bug 1083344.

Maybe this also helps: I'm on a MacBook Pro (Retina, 15-inch, Late 2013) with 10.10. Jed, what machine and OS do you use?

4:44.38 LOG: MainThread Bisector INFO Last good revision: 5de3af90c494 4:44.38 LOG: MainThread Bisector INFO First bad revision: 0cefb584fd1a

And the pushlog which introduced the problem: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5de3af90c494&tochange=0cefb584fd1a Still running through inbound builds now...

29:46.37 LOG: MainThread Bisector INFO Last good revision: 3df9f4282a65 29:46.37 LOG: MainThread Bisector INFO First bad revision: a0b805de0c8e 29:46.37 LOG: MainThread Bisector INFO Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=3df9f4282a65&tochange=a0b805de0c8e Looks like you are probably right jib about bug 1083344.

Maybe check your /var/log/system.log for signs of denied access at the time of gUM? See Bug 1083344 comment 44. I'm on a MacBook Pro (Retina, 15-inch, Mid 2012) with 10.9.5 and cannot reproduce.

Hi André, just wanted to let you know that a few people on macs aren't able to access camera through gUM at all on Nightly since Saturday (see comment 20). Bug 1083344 is the prime suspect, so we were wondering if you had any tips on verifying or solving this.

(In reply to Nils Ohlmeier [:drno] from comment #17) > I'm on a MacBook Pro (Retina, 15-inch, Late 2013) with 10.10. > > Jed, what machine and OS do you use? MacBook Pro (Retina, 15-inch, Mid 2014), 10.10.2. And, indeed, this shows up in system.log when I try to use Hello: Feb 25 22:43:14 nimbostratus kernel[0]: Sandbox: plugin-container(24896) deny mach-lookup com.apple.cmio.AppleCameraAssistant

Setting security.sandbox.macos.content.level to 0 and restarting causes camera access to work normally.

(In reply to Jan-Ivar Bruaroey [:jib] from comment #22) > Hi André, just wanted to let you know that a few people on macs aren't able > to access camera through gUM at all on Nightly since Saturday (see comment > 20). Bug 1083344 is the prime suspect, so we were wondering if you had any > tips on verifying or solving this. Thanks for reporting, and especially for the relevant line in the system log. I'll be able to add a corresponding allow rule, likely today (together with other needed changes).

(In reply to Jan-Ivar Bruaroey [:jib] from comment #22) Jan-Ivar, my patch is ready for review in bug 1083344. It would be helpful if you could verify that it fixes this bug before it lands.

(In reply to André Reinald from comment #26) > Jan-Ivar, my patch is ready for review in bug 1083344. It would be helpful > if you could verify that it fixes this bug before it lands. I don't have a problem system myself, but drno does, and blassey (on 10.9.5?) I think. Lateraling to them.

In case it helps, I've started a tryserver build with André's latest patch from bug 1083344: https://treeherder.mozilla.org/#/jobs?repo=try&revision=940c1eb2c602 When it becomes available, please test with it. First set security.sandbox.macos.content.level to '1' in about:config, then restart. You will also (of course) need to be running in e10s mode.

(In reply to André Reinald from comment #26) > (In reply to Jan-Ivar Bruaroey [:jib] from comment #22) > > Jan-Ivar, my patch is ready for review in bug 1083344. It would be helpful > if you could verify that it fixes this bug before it lands. Just checked that the patch in bug 1083344 fixes the camera issue.

It is not clear to me that this is the bug I was hitting before

To keep our stats accurate: this got fixed through this checkin https://hg.mozilla.org/mozilla-central/rev/4670e746db40 in https://bugzilla.mozilla.org/show_bug.cgi?id=1083344#c193