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

Categories

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

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla19
Tracking Status
firefox18 --- affected
firefox19 --- verified

People

(Reporter: jsmith, Unassigned)

References

Details

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

Attachments

(2 files)

Steps:

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

Expected:

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

Actual:

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 http://timtaubert.de/demos/green-screen/
* 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+
https://hg.mozilla.org/mozilla-central/rev/58c8080a1a7c
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Keywords: verifyme
Verified on 10/26 build.
Status: RESOLVED → VERIFIED
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.