Reproducible with latest Developer Edition 42.0a2 and Nightly 43.0a1 with e10s enabled Affected platforms: Windows 7 x64, Windows 10 x86 and Ubuntu 14.04 x86 Precondition: two PCs, webcam and microphone. Steps to reproduce: 1. On PC1: start Firefox and Click on Hello icon (chat bubble with smiley face). 2. Click on "Start a conversation" 3. Send and join the conversation from PC2. 4. On PC2: Click on Hello icon and start a conversation. Expected result: Camera and microphone are automatically shared. Actual result: 'No camera or microphone found.' message displayed in the conversation window. Additional notes: 1. Not reproducible under Mac OS X 10.10.4 nor with e10s disabled. 2. Unable to reproduce on link-creator side. 3. Browser console output: OT.Publisher.onStreamAvailableError SourceUnavailableError: Unknown Error while getting user media sdk.js:3399:13 OT.exception :: title: Unable to Publish (1500) msg: GetUserMedia sdk.js:3399:13 1500 Unknown Error while getting user media sdk.js:3399:13 OT.exception :: title: Unable to Publish (1500) msg: Unknown Error while getting user media sdk.js:3399:13

can't reproduce on Mac 10.9.5 either with Nightly <-> Release

Here is the regression range: (m-c): Last good revision: d3228c82badd First bad revision: 33dc8a83cfc0 Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d3228c82badd&tochange=33dc8a83cfc0 (m-i): Last good revision: 8541ce2730c0 First bad revision: e039b166890f Pushlog: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8541ce2730c0&tochange=e039b166890f

Mark, you're in the inbound regression range

None of the changes we landed would have affected the link-clicker - that has a separate deployment process, even if the dev servers were used, it should have been consistent for the time of the testing. This would point to something in browser land (which we haven't been touching). At the moment I can't reproduce this. I'm wondering if Bogdan can since Alexandra appears to be afk.

I successfully reproduced this issue on Ubuntu 14.04 32-bit and Windows 10 64-bit (_NOT_ on Mac OS X 10.10.4 as stated in comment 0) with both loop servers, default and dev-server, on link clicker side I receive 'No camera or microphone found' if I start a conversation while already in one. Please let me know if there is anything I can help with further on.

Maire, any ideas?

Currently in e10s you can't have 2 processes accessing the cameras at the same time on Linux and Windows. (Mac permits it.) The good news is I believe gcp's video sandboxing work should fix this, and that is hopefully (fingers crossed) landing this week.

gcp, can you test with your current patches and dupe if they fix this?

I tested this with my patches. They produce the same result. Log: -274733312[7f74063d8660]: Capture Device allocated: 4097 -274733312[7f74063d8660]: Video device 4097 allocated -274733312[7f74063d8660]: Audio config: aec: 1, agc: -1, noise: 1 -274733312[7f74063d8660]: Start audio for stream 7f73e51fb880 -274733312[7f74063d8660]: Audio config: aec: 0, agc: -1, noise: 0 -274733312[7f74063d8660]: virtual nsresult mozilla::MediaEngineRemoteVideoSource::Start(mozilla::SourceMediaStream*, mozilla::TrackID) -274733312[7f74063d8660]: int mozilla::camera::CamerasChild::StartCapture(mozilla::camera::CaptureEngine, int, webrtc::CaptureCapability&, webrtc::ExternalRenderer*) 159377152[7f740a9e4800]: virtual bool mozilla::camera::CamerasParent::RecvStartCapture(const int&, const int&, const CaptureCapability&) 159377152[7f740a9e4800]: bool mozilla::camera::CamerasParent::EnsureInitialized(int) -266340608[7f74063d89c0]: virtual bool mozilla::camera::CamerasChild::RecvReplyFailure() -274733312[7f74063d8660]: StartCapture failed -274733312[7f74063d8660]: Starting video failed , rv=-2147467259 -274733312[7f74063d8660]: Audio device 0 deallocated -274733312[7f74063d8660]: virtual nsresult mozilla::MediaEngineRemoteVideoSource::Stop(mozilla::SourceMediaStream*, mozilla::TrackID) -274733312[7f74063d8660]: int mozilla::camera::CamerasChild::StopCapture(mozilla::camera::CaptureEngine, int) The second session tries to open the camera, which is already allocated elsewhere, so it fails. I'm going to check the non-e10s cases now.

My patches don't regress the non-e10s-case. Yay. I noticed that in this case the camera is recognized as Allocated Shared.

I'm seeing the secondary CamerasParent object being constructed in the parent and it attempting to reopen the camera. Given that these are now in the same process, that shouldn't fail, but it does. I think the underlying problem is not the actual Cameras, but MediaEngineWebRTCVideo (now MediaEngineRemoteVideoSource) being unshared in e10s mode, and probably mState not understanding that the device is already allocated because there's 2 copies of that var.

To clarify, this problem exists when you try to have 2 conversations going on at the same time, and at least one of those is in Hello.

Mass change P2->P3 to align with new Mozilla triage process.