[e10s] gUM video fails to detect camera on MacBook Pro

RESOLVED FIXED

Status

()

RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: jld, Assigned: drno)

Tracking

({regression})

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.
Flags: needinfo?(jld)
(Reporter)

Comment 2

4 years ago
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.
(Reporter)

Comment 3

4 years ago
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.
Flags: needinfo?(jld)
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
Summary: Firefox Hello broken in nightly: NS_ERROR_FAILURE: PeerConnection.js:373:0 → [e10s] Firefox Hello broken in nightly: NS_ERROR_FAILURE: PeerConnection.js:373:0
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)?
(Assignee)

Comment 6

4 years ago
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.
(Assignee)

Comment 7

4 years ago
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.
(Reporter)

Comment 9

4 years ago
(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.
(Assignee)

Updated

4 years ago
Assignee: nobody → drno
(Assignee)

Comment 10

4 years ago
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...
(Assignee)

Comment 11

4 years ago
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.
Summary: [e10s] Firefox Hello broken in nightly: NS_ERROR_FAILURE: PeerConnection.js:373:0 → [e10s] gUM video constraints don't make it to the door hanger dialog
Anything with NSPR_LOG_MODULES=MediaManager:5 ?
(Assignee)

Comment 13

4 years ago
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.
(Assignee)

Updated

4 years ago
Summary: [e10s] gUM video constraints don't make it to the door hanger dialog → [e10s] gUM video fails to detect camera on MacBook Pro
(Assignee)

Comment 14

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

Comment 15

4 years ago
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.
(Assignee)

Comment 17

4 years ago
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?
Flags: needinfo?(jld)
(Assignee)

Comment 18

4 years ago
4:44.38 LOG: MainThread Bisector INFO Last good revision: 5de3af90c494
4:44.38 LOG: MainThread Bisector INFO First bad revision: 0cefb584fd1a
(Assignee)

Comment 19

4 years ago
And the pushlog which introduced the problem: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5de3af90c494&tochange=0cefb584fd1a

Still running through inbound builds now...
(Assignee)

Comment 20

4 years ago
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.
Depends on: 1083344
Keywords: regression
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.
Flags: needinfo?(areinald)
(Reporter)

Comment 23

4 years ago
(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
Flags: needinfo?(jld)
(Reporter)

Comment 24

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

Comment 25

4 years ago
(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).
Flags: needinfo?(areinald)

Comment 26

4 years ago
(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.
Flags: needinfo?(jib)
Depends on: 1104616
(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.
Flags: needinfo?(jib)
Flags: needinfo?(drno)
Flags: needinfo?(blassey.bugs)
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.
(Assignee)

Comment 29

4 years ago
(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.
Flags: needinfo?(drno)
It is not clear to me that this is the bug I was hitting before
Flags: needinfo?(blassey.bugs)

Updated

4 years ago
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
(Assignee)

Comment 31

4 years ago
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
Resolution: WORKSFORME → FIXED
You need to log in before you can comment on or make changes to this bug.