Closed Bug 802397 Opened 7 years ago Closed 7 years ago

If I try to get access to my USB camera with a USB camera and built-in camera plugged in, I end up getting the built-in camera instead


(Core :: WebRTC: Audio/Video, defect)

Not set



Tracking Status
firefox18 --- affected
firefox19 --- verified


(Reporter: jsmith, Unassigned)



(Whiteboard: [getUserMedia] [blocking-gum+])


(2 files)


1. Call gUM with video with an integrated camera and USB camera on your device
2. When the permission prompt appears, select the USB camera


The USB camera should start streaming and be shown in the video tag using the media stream from gUM.


The integrated camera starts streaming and is shown in the video tag using the media stream from gUM.
Blocks: 729522
Whiteboard: [getUserMedia]
Sounds like bug 797796 isn't working as expected, unless the front-end is sending bogus data to the back-end.
Component: General → WebRTC: Audio/Video
Product: Firefox → Core
QA Contact: jsmith
Spoke with Anant about this today - this is more likely a core webrtc bug.
Whiteboard: [getUserMedia] → [getUserMedia] [blocking-gum+]
jsmith, can you retest with today's nightly or a fresh build?
Keywords: qawanted
(In reply to Randell Jesup [:jesup] from comment #3)
> jsmith, can you retest with today's nightly or a fresh build?

Yup, retested. I can still reproduce this bug.
Keywords: qawanted
This is easy for me to reproduce on OSX, current nightly:

* Plug in USB camera to MacBook
* Load
* Give it permission for the USB cam

Instead of video from the USB cam, I get the built-in camera.
Attached patch Uhh, what?Splinter Review
So, from some debugging I found that the frontend code was passing the wrong device to the MediaManager observer.

This patch adds logging and makes it work, but I don't understand what's going on... The logging prints:

Allow: FaceTime HD Camera (Built-in) for callID {de506c63-8a26-9e42-a914-0aeaefc1352e}
Allow: USB 2.0 PC Cam for callID {de506c63-8a26-9e42-a914-0aeaefc1352e}

So ddd != device, and indeed passing |ddd| to .notifyObservers fixes things.

But AFAIK there should be a closure over |device| here, so the code _should_ work as-is. Ergo, JS engine bug. Or am I missing something?
I see the same thing; it *appears* as if device remains a reference to an outer context.  Odd.

BTW, I see this on Linux and windows as well; I doubt it's OS-related.

We should probably do a minimal testcase to verify.
OS: Windows 7 → All
The fine folks in #jsapi say this is bug 449811.
Depends on: 449811
// standalone testcase that's now irrelevant deleted....

Sheesh.  4-year old bug, with a 9-month-old r+'d patch....
Let's land ttaubert's fix (minus dumps) with a comment that it's that bug, and point them in that bug to fix the js code when they land that engine fix.
Attachment #674811 - Flags: review?(dolske)
Attachment #674811 - Flags: review?(dolske) → review+
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Keywords: verifyme
Verified on 10/26 build.
Keywords: verifyme
If we could fake the devices, we might be able to automate this. Although as it stands in the current framework, we don't have this ability. Putting in-testsuite- for now, although if device faking becomes possible at some point, then we should re-evaluate this one for a test.
Flags: in-testsuite-
Depends on: 815002
You need to log in before you can comment on or make changes to this bug.