729522 - Implement WebRTC navigator.getUserMedia() user interface

Status: VERIFIED FIXED

(Firefox :: Site Permissions, defect)

Description

[Randell Jesup [:jesup] (needinfo me)]

See Boriss's preliminary design (positively received at W3C).  Should allow for previewing and selection of camera, mics; preferably keep associated cameras/mics together.  Selecting audio-only must be easy.   If an application requests, may need to allow selecting multiple cameras/mics, and possibly selecting a (video or image) file in place of a camera.  When hinted to as an option, would also provide access to screen-sharing (window, whole screen).

For static image capture, there will be a need for video preview and then high-resolution capture (though this will likely be through other lower-level APIs once getUserMedia has selected a camera).

Acts as both selection dialog and security doorhanger.

It may need an alternate mode (invoked via hints) for immediate image capture without a second click/dialog in the application (to address UI issues for apps that just need to get a snapshot).

Comment 1

[[:fabrice] Fabrice Desré]

Randell, can you add a link to the mockups?

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

http://new.tinygrab.com/08092efbdd03a3bafe1718fcf0c0bbd6a75aa30e37.jpg

Comment 3

[brian]

Please consider the ability to share a fake stream without informing the application/website. Take for example the following scenario:

- 14-year old kid wants to use popular social networking site
- popular social networking site wants to use face tracking to figure out when kid is paying attention, which friends are with them.
- popular social networking site prompts: if you want to use all our features, you need to enable your webcam
- kid feels social pressure to use site, struggles to weigh value of privacy.

Would be great if there was a built-in fake webcam, selection of which would tell the application/site that it's a real camera but stream fake video. Optional sources would include:
- "static" noise
- blank screen
- local video file looping
- animated perlin noise (in case application detects frozen/blank fake video)

Consider something analogous for audio.

Please also consider the ability for sites to use camera/mic specs to profile individual visitors.

The mockup looks great. It may be helpful to also provide a preview of what the camera is broadcasting. Maybe even a very small version as an icon in the tab or next to the URL bar. You wouldn't be able to see much, but the constant subtle movement might serve as a reminder that you're being watched.

Anything that reminds the user that recording/streaming is happening would be helpful, especially for audio. Most laptops at least have a little LED that indicates when the webcam is on, but there is no indication that the microphone is active. This is sensitive enough that I'd prefer to err on the side of going overboard.

We discussed these issues and others at the Open Video Conference. Anant led the session, so he may remember the discussion and have notes. Some notes are linked here:
http://openvideoconference.org/device-inputs-av-in-the-browser/

Thanks.

Comment 5

[Maire Reavy [:mreavy]]

Attachment: gUM UX design - first iteration

If anyone in addition to Boriss is needed for the UI review, please add them.

Comment 6

[Dão Gottwald [:dao]]

Comment on attachment 664949 [details]
gUM UX design - first iteration

This streaming notification on tabs isn't going to fly. Apart from it being somewhat weird and the line potentially being incompatible with the way background tabs are styled with the Australis redesign, we cannot display two icons in pinned tabs.

Comment 7

[Maire Reavy [:mreavy]]

(In reply to Dão Gottwald [:dao] from comment #6)
> Comment on attachment 664949 [details]
> gUM UX design - first iteration
> 
> This streaming notification on tabs isn't going to fly. Apart from it being
> somewhat weird and the line potentially being incompatible with the way
> background tabs are styled with the Australis redesign, we cannot display
> two icons in pinned tabs.

Dão -Thanks for flagging this!  Anant and I will circle with Boriss and discuss what else is possible for streaming notification.  I don't believe this issue is blocking other work on this bug yet.  Am I correct?

Comment 8

[Dão Gottwald [:dao]]

Yes, in fact you might want to spin it off to a separate bug.

Comment 9

[Madhava Enros [:madhava]]

Just so this doesn't get lost -- quick attempt by shorlander of an Australis friendly version:
http://cl.ly/image/0l0H2z2H0w0o

Comment 10

[Madhava Enros [:madhava]]

Just so this doesn't get lost -- quick attempt by shorlander of an Australis friendly version:
http://cl.ly/image/0l0H2z2H0w0o

Comment 11

[Jason Smith [:jsmith]]

Hi Dao and ff-ux - I'm the QA testing this. I have few random questions for the UX spec:

- How are you handling selecting a particular camera or mic if I had multiple cameras hooked up to my PC? Chrome appears to support this (just tested with http://shinydemos.com/3d-color-histogram/ with my integrated and USB cameras hooked in)

- Are the share options basically:
** Share Camera with video only requested - Share Camera or Don't Share
** Share Microphone with audio only requested - Share Microphone or Don't Share
** Share Camera and Microphone (shouldn't this be singular?) - a bit more confused on this one. Is there any granularity to options here? Something like Share Camera and Microphone, Share Camera Only, Share Mic Only, Don't Share? Or just the general use case - Share Camera and Microphone or Don't Share?

Comment 12

[Dão Gottwald [:dao]]

Attachment: stub UI

major missing pieces:
- invocation (does the backend send any notifications?)
- distinction between webcam and audio-only (depends on invocation)
- multiple-webcam handling (depends on invocation)
- communicating the user choice back to gecko
- shippable icons (shorlander?)

Comment 13

[Anant Narayanan [:anant]]

(In reply to Dão Gottwald [:dao] from comment #12)
> major missing pieces:
> - invocation (does the backend send any notifications?)
> - distinction between webcam and audio-only (depends on invocation)
> - multiple-webcam handling (depends on invocation)
> - communicating the user choice back to gecko

Hey Dão, I've added comments to the appropriate places in MediaManager.cpp where the UI should be invoked and the results should be passed back to the code: https://mxr.mozilla.org/mozilla-central/source/dom/media/MediaManager.cpp#598

Feel free to add the notification code, or simple invoke/callback, or any other means by which you want the backend and UI to communicate! If you want me to implement some specific form, i'd be happy to do that as well.

Comment 14

[Anant Narayanan [:anant]]

You'll also want to use navigator.mozGetUserMediaDevices to enumerate available devices to let the user select a particular device in addition to just a allow/deny choice. Previews for those devices would be smashing!

Comment 15

[Dão Gottwald [:dao]]

(In reply to Anant Narayanan [:anant] from comment #13)
> Feel free to add the notification code, or simple invoke/callback, or any
> other means by which you want the backend and UI to communicate! If you want
> me to implement some specific form, i'd be happy to do that as well.

I don't feel qualified to do this, surely not in the next few days if you want this to land in this cycle. So yeah, I'd appreciate your help. I have no real preference regarding the form, I just need the relevant data (XPCOM observer notifications or custom chrome-only DOM events are often used for this) and some way to talk back.

(In reply to Anant Narayanan [:anant] from comment #14)
> You'll also want to use navigator.mozGetUserMediaDevices to enumerate
> available devices to let the user select a particular device in addition to
> just a allow/deny choice. Previews for those devices would be smashing!

Attachment 664949 [details] doesn't seem to care about selecting a particular device. Previews I'd also spin off to a separate bug for the sake of getting this landed asap.

Comment 16

[Anant Narayanan [:anant]]

Attachment: gUM UX design - second iteration

(In reply to Dão Gottwald [:dao] from comment #15)
> (In reply to Anant Narayanan [:anant] from comment #13)
> > Feel free to add the notification code, or simple invoke/callback, or any
> > other means by which you want the backend and UI to communicate! If you want
> > me to implement some specific form, i'd be happy to do that as well.
> 
> I don't feel qualified to do this, surely not in the next few days if you
> want this to land in this cycle. So yeah, I'd appreciate your help. I have
> no real preference regarding the form, I just need the relevant data (XPCOM
> observer notifications or custom chrome-only DOM events are often used for
> this) and some way to talk back.

Ok sounds good, I'll cook something up over the weekend.

> (In reply to Anant Narayanan [:anant] from comment #14)
> > You'll also want to use navigator.mozGetUserMediaDevices to enumerate
> > available devices to let the user select a particular device in addition to
> > just a allow/deny choice. Previews for those devices would be smashing!
> 
> Attachment 664949 [details] doesn't seem to care about selecting a
> particular device. Previews I'd also spin off to a separate bug for the sake
> of getting this landed asap.

The attachment is outdated, here's the updated one. We do want device selection at the very least, if not previews, otherwise what was the point of blocking on bug 752352? We can move previews to a follow-up bug.

Comment 17

[Dão Gottwald [:dao]]

(In reply to Anant Narayanan [:anant] from comment #14)
> You'll also want to use navigator.mozGetUserMediaDevices to enumerate
> available devices to let the user select a particular device in addition to
> just a allow/deny choice.

Components.classes.nsIMediaDevice appears to be undefined over here. Is this expected? media.navigator.enabled is set to true, in case this matters.

Comment 18

[Anant Narayanan [:anant]]

(In reply to Dão Gottwald [:dao] from comment #17)
> (In reply to Anant Narayanan [:anant] from comment #14)
> > You'll also want to use navigator.mozGetUserMediaDevices to enumerate
> > available devices to let the user select a particular device in addition to
> > just a allow/deny choice.
> 
> Components.classes.nsIMediaDevice appears to be undefined over here. Is this
> expected? media.navigator.enabled is set to true, in case this matters.

Do you mean Components.interfaces.nsIMediaDevice? It should be defined.

I put up an example here: https://gist.github.com/3744555 - does that work?

Comment 19

[Dão Gottwald [:dao]]

(In reply to Anant Narayanan [:anant] from comment #18)
> (In reply to Dão Gottwald [:dao] from comment #17)
> > (In reply to Anant Narayanan [:anant] from comment #14)
> > > You'll also want to use navigator.mozGetUserMediaDevices to enumerate
> > > available devices to let the user select a particular device in addition to
> > > just a allow/deny choice.
> > 
> > Components.classes.nsIMediaDevice appears to be undefined over here. Is this
> > expected? media.navigator.enabled is set to true, in case this matters.
> 
> Do you mean Components.interfaces.nsIMediaDevice?

Ooops, yes! I think I copied the above directly from my testing code, so this explains why it didn't.

Comment 20

[Dão Gottwald [:dao]]

Attachment: WIP patch v2

Device selection added.

Note: The popup notification API allows for secondary actions that directly execute something. It doesn't allow for radio or checkbox menu items. This makes it impractical to allow the user to select arbitrary camera and microphone combinations. So what I did is allow the user to select either a specific camera if applicable (which might automatically include a mic) or a sepcific mic.

Comment 21

[Anant Narayanan [:anant]]

Attachment: Part 1: UI for getUserMedia

I modified Dao's patch to listen for an incoming observer notification as well as dispatch an outgoing notification after the user has made a selection.

Comment 22

[Anant Narayanan [:anant]]

Attachment: Part 2: Hookup gUM backend with the UI

Randell, feel free to reassign the review to jst if you think you won't have time to go through it, he knows this code pretty well :)

Comment 23

[Anant Narayanan [:anant]]

Attachment: Part 2: Hookup gUM backend with the UI

Forgot to not ask permission when called from privileged code!

Comment 24

[Dão Gottwald [:dao]]

Comment on attachment 667801 [details] [diff] [review]
Part 1: UI for getUserMedia

>+  observe: function(aSubject, aTopic, aData) {
>+    if (aTopic != "getUserMedia:request") {
>+      return;
>+    }
>+    try {
>+      let params = aSubject.QueryInterface(Ci.nsIMediaStreamOptions);
>+      this.handleRequest(aData, params);
>+    } catch(e) {
>+      Cu.reportError(e);
>+    }

When does this throw?

>+  prompt: function(aRequestID, aAudio, aVideo, aDevices) {

>+    let browser = gBrowser.selectedBrowser;

This was just a placeholder. The request could come from a background tab, as I understand it.

Comment 25

[Dão Gottwald [:dao]]

Comment on attachment 667810 [details] [diff] [review]
Part 2: Hookup gUM backend with the UI

We need the content window in order to show the UI in the right browser window and for the right tab. I spun all of this off to bug 797796.

Comment 26

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 667810 [details] [diff] [review]
Part 2: Hookup gUM backend with the UI

Review of attachment 667810 [details] [diff] [review]:
-----------------------------------------------------------------

All looks good to me, though this patch was obsoleted by Dao.  Once we have a new patch we can get a reviewer (or if this patch should have just been moved to the new bug).

::: dom/media/MediaManager.cpp
@@ +807,5 @@
> +    // Close off any remaining active windows.
> +    mActiveWindows.Clear();
> +    mActiveCallbacks.Clear();
> +    sSingleton = nullptr;
> +    

Trailing spaces in here in a few spots

Comment 27

[Dão Gottwald [:dao]]

Attachment: WIP patch v4

Comment 28

[Anant Narayanan [:anant]]

Thanks Dao. As discussed on IRC, i'll make aData a JSON string as follows:

{windowID: 1234, callID: foo}

where windowID is the outer window ID (a 64 bit integer) and callID is a UUID, as before. Note that for the allow/deny messages from the UI to the backend, only send the callID and not the JSON structure (we don't need the windowID on the trip back).

(In reply to Dão Gottwald [:dao] from comment #24)
> >+    try {
> >+      let params = aSubject.QueryInterface(Ci.nsIMediaStreamOptions);
> >+      this.handleRequest(aData, params);
> >+    } catch(e) {
> >+      Cu.reportError(e);
> >+    }
> 
> When does this throw?

Originally, I used JSON.parse on aData because I was feeding audio/video booleans there, guess we're back to a similar scheme!

Comment 29

[Dão Gottwald [:dao]]

I'd trust the backend to produce valid JSON and even if it didn't, letting the exception go uncaught shouldn't break anything else, AIUI.

Comment 30

[Dão Gottwald [:dao]]

Attachment: WIP patch v5

entirely untested, waiting for bug 797796

Comment 31

[Dão Gottwald [:dao]]

Attachment: WIP patch v5

uploaded the wrong patch...

Comment 32

[Anant Narayanan [:anant]]

Uploaded a patch to bug 797796, you can run a test at https://people.mozilla.com/~anarayanan/gum_test.html

Comment 33

[Dão Gottwald [:dao]]

Attachment: WIP patch v6

Comment 34

[Dão Gottwald [:dao]]

Comment on attachment 668121 [details] [diff] [review]
WIP patch v6

>+  let contentWindow = someWindow.QueryInterface(Ci.nsIInterfaceRequestor)
>+                                .getInterface(Ci.nsIDOMWindowUtils)
>+                                .getOuterWindowWithId(windowID);

For some reason getOuterWindowWithId returns null here...

Comment 35

[Dão Gottwald [:dao]]

Attachment: patch

The patch in bug 797796 currently sends the inner window's ID. With that changed to the outer window's ID, things work.

Comment 36

[Justin Dolske [:Dolske]]

Comment on attachment 668172 [details] [diff] [review]
patch

Review of attachment 668172 [details] [diff] [review]:
-----------------------------------------------------------------

The mockups here include a persistent indicator to show when a tab is using a device -- but I don't see that in the patch? Did the design change, or is there a separate bug / followup? Seems like an important thing to have. I'm going to mark r+ on the assumption that there is a plan (and the other comments I've made are easily addressable), but an note for what the plan is would be helpful in this bug.

There's more cleanup in winstripe/jar.mn than I'd prefer... Ok to land as-is, but ideally it would be in a different changeset/bug. (I'm ok with this kind of trivial cleanup landing self-reviewed too.) Just makes it harder to see what changes are actually needed, and avoids losing the cleanup should there be a backout. ;)

I'd really like to see a test here (followup?), but I can see how that could be hard since it would depend on the particular hardware attached (or not) to a test machine. I'd suspect this is a common issue with WebRTC stuff, maybe we need (have?) a dummy/stub driver.

::: browser/modules/getUserMediaUI.jsm
@@ +3,5 @@
> + * You can obtain one at http://mozilla.org/MPL/2.0/. */
> +
> +"use strict";
> +
> +let EXPORTED_SYMBOLS = ["getUserMediaUI"];

If I had to bikeshed here, I'd suggest something along the lines of "webrtcUI.jsm". IF I had to. Which I don't. So I won't. ;)

[I only mention it because I can see ambiguity between "UI for gUM" and "get the user's media UI". No big deal.]

@@ +21,5 @@
> +}
> +
> +function observer(aSubject, aTopic, aData) {
> +  if (aTopic != "getUserMedia:request")
> +    return;

Any particular reason for this? It's just a sanity check that shouldn't ever actually fail, right?

@@ +46,5 @@
> +    }
> +  );
> +}
> +
> +function prompt(aBrowser, aCallID, aAudio, aVideo, aDevices) {

I'm not a fan of aFoo, but it's especially confusing here because he arguments (and IDL, frankly) are generic enough that the meaning is unclear.

Looks like these really should be called wantsAudio / wantsVideo. That would make the code here more self-documenting.

@@ +50,5 @@
> +function prompt(aBrowser, aCallID, aAudio, aVideo, aDevices) {
> +  let audioDevices = [];
> +  let videoDevices = [];
> +  for (let device of aDevices) {
> +    device = device.QueryInterface(Ci.nsIMediaDevice);

Seems like this shouldn't be needed. Is there some bad IDL or missing classInfo somewhere?

@@ +91,5 @@
> +    }
> +  };
> +
> +  let secondaryActions = [];
> +  let selectableDevices = videoDevices.length ? videoDevices : audioDevices;

Who/what ends up selecting an audio device when both types of devices are present?

@@ +101,5 @@
> +                 device.type == "audio" ?
> +                   "getUserMedia.shareSpecificMicrophone.label" :
> +                   "getUserMedia.shareSpecificCamera.label",
> +                 [ device.name ]),
> +        accessKey: ++selectableDeviceNumber,

Move the increment out so that it's just explicitly incremented, once, each for-loop. Having it buried in the push() makes me worry about some (bad) future change referring to it twice (which would get the value wrong in one case, and then you've accidentally selected an unexpected device. :-o)

Comment 37

[Jason Smith [:jsmith]]

(In reply to Justin Dolske [:Dolske] from comment #36)
> Comment on attachment 668172 [details] [diff] [review]
> patch
> 
> Review of attachment 668172 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I'd really like to see a test here (followup?), but I can see how that could
> be hard since it would depend on the particular hardware attached (or not)
> to a test machine. I'd suspect this is a common issue with WebRTC stuff,
> maybe we need (have?) a dummy/stub driver.

FYI - We do have a way to fake the hardware on the machine using a "fake" media stream. You need to call mozGetUserMedia with {fake: true} to use the "fake" media stream. So its should definitely be possible to get an automated test here.

More details in bug 794668.

Comment 38

[Jason Smith [:jsmith]]

(In reply to Jason Smith [:jsmith] from comment #37)
> (In reply to Justin Dolske [:Dolske] from comment #36)
> > Comment on attachment 668172 [details] [diff] [review]
> > patch
> > 
> > Review of attachment 668172 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > I'd really like to see a test here (followup?), but I can see how that could
> > be hard since it would depend on the particular hardware attached (or not)
> > to a test machine. I'd suspect this is a common issue with WebRTC stuff,
> > maybe we need (have?) a dummy/stub driver.
> 
> FYI - We do have a way to fake the hardware on the machine using a "fake"
> media stream. You need to call mozGetUserMedia with {fake: true} to use the
> "fake" media stream. So its should definitely be possible to get an
> automated test here.
> 
> More details in bug 794668.

One thing to fix on that above comment (just tested the fake media stream actually) - you do the following:

- get a fake video stream = {fake: true, video: true} in the first gUM param
- get a fake audio stream = {fake: true, audio: true] in the first gUM param

Comment 39

[Maire Reavy [:mreavy]]

(In reply to Justin Dolske [:Dolske] from comment #36)
> Comment on attachment 668172 [details] [diff] [review]
> patch
> 
> Review of attachment 668172 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> The mockups here include a persistent indicator to show when a tab is using
> a device -- but I don't see that in the patch? Did the design change, or is
> there a separate bug / followup? Seems like an important thing to have. I'm
> going to mark r+ on the assumption that there is a plan (and the other
> comments I've made are easily addressable), but an note for what the plan is
> would be helpful in this bug.
> 

In order to pref this on, we need a persistent indicator, but per comment #6 on this bug, we can't display 2 icons in pinned tabs.  So before we pref this on, we need to either solve the technical limitation of displaying 2 icons or come up with a design alternative.  Also before we pref this on, we want a persistent indicator that is visible to the user even when the browser window is obscured.  The privacy team will be evaluating this design soon, and the persistent indicator icon design is subject to change as we go through their review.

Comment 40

[Justin Dolske [:Dolske]]

(In reply to Maire Reavy [:mreavy] from comment #39)

> In order to pref this on, we need a persistent indicator, but per comment #6
> on this bug, we can't display 2 icons in pinned tabs. [...]

Ok, thanks! Is there already a bug on file for this?

Comment 41

[Dão Gottwald [:dao]]

Attachment: patch v2

(In reply to Justin Dolske [:Dolske] from comment #36)
> The mockups here include a persistent indicator to show when a tab is using
> a device -- but I don't see that in the patch? Did the design change, or is
> there a separate bug / followup? Seems like an important thing to have. I'm
> going to mark r+ on the assumption that there is a plan (and the other
> comments I've made are easily addressable), but an note for what the plan is
> would be helpful in this bug.

I'll file a bug. I think we need a new design here and I have an idea what could be done if nobody comes up with something smarter.

> If I had to bikeshed here, I'd suggest something along the lines of
> "webrtcUI.jsm". IF I had to. Which I don't. So I won't. ;)
> 
> [I only mention it because I can see ambiguity between "UI for gUM" and "get
> the user's media UI". No big deal.]

made this change

> > +function observer(aSubject, aTopic, aData) {
> > +  if (aTopic != "getUserMedia:request")
> > +    return;
> 
> Any particular reason for this? It's just a sanity check that shouldn't ever
> actually fail, right?

Right, I put it there because "observer" might sound like it handles arbitrary notifications. I renamed it to handleRequest.

> > +function prompt(aBrowser, aCallID, aAudio, aVideo, aDevices) {
> 
> I'm not a fan of aFoo, but it's especially confusing here because he
> arguments (and IDL, frankly) are generic enough that the meaning is unclear.
> 
> Looks like these really should be called wantsAudio / wantsVideo. That would
> make the code here more self-documenting.

renamed to aAudioRequested, aVideoRequested

> > +    device = device.QueryInterface(Ci.nsIMediaDevice);
> 
> Seems like this shouldn't be needed. Is there some bad IDL or missing
> classInfo somewhere?

Looks like it. This doesn't currently work without QueryInterface.

> Who/what ends up selecting an audio device when both types of devices are
> present?

I expected there to be a default selection, but I don't know. Asking for clarification in bug 797796.

> > +        accessKey: ++selectableDeviceNumber,
> 
> Move the increment out so that it's just explicitly incremented, once, each
> for-loop.

done

Comment 42

[Randell Jesup [:jesup] (needinfo me)]

Great!  Let's get this UI landed before FF18 uplift - if we can get a persistent indicator by then, wonderful, but getting this in should take precedence.  Once we have a persistent indicator, we can ask for that to be uplifted to Aurora/FF18.

Comment 43

[Anant Narayanan [:anant]]

Comment on attachment 668375 [details] [diff] [review]
patch v2

Agreed!

One last thing to do before landing this, I pushed Dao's latest patch and the patch from bug 79796 to try: https://tbpl.mozilla.org/?tree=Try&rev=5a87868ad982 - Boriss can you do a ui-review when builds from that push are ready? (they will be at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-5a87868ad982)

Alternatively, I could take screenshots for what the UI looks like in practice, if that's easier for you.

Comment 44

[Anant Narayanan [:anant]]

Attachment: Permission dialog on Linux

For reference, this is what the implemented UI looks like on Linux, with a single camera, when video is requested.

Comment 45

[Anant Narayanan [:anant]]

Let's try try again: https://tbpl.mozilla.org/?tree=Try&rev=2dfe70dfcef1
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-2dfe70dfcef1

Comment 46

[Anant Narayanan [:anant]]

Dao, I'm committing the UI as-is, we can upload the new images from bug 798336 when they're ready (and perhaps uplift to Aurora).

https://hg.mozilla.org/integration/mozilla-inbound/rev/b9de5da14ab0

Comment 47

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/b9de5da14ab0

Comment 48

[Jason Smith [:jsmith]]

On Mac, I'm seeing the camera prompt appearing and allowing me to enable/disable access to the camera/microphone. However, I'm not seeing these prompts at all on windows, which sends the perception that gUM is broken on windows. Dao - Is this working for you on windows?

Comment 49

[John Drinkwater (:beta)]

(In reply to Jason Smith [:jsmith] from comment #48)
> On Mac, I'm seeing the camera prompt appearing and allowing me to
> enable/disable access to the camera/microphone. However, I'm not seeing
> these prompts at all on windows, which sends the perception that gUM is
> broken on windows. Dao - Is this working for you on windows?

Having a similar issue on Linux, Nightly 19.0a1 (2012-10-12) is showing the door‐hanger but cannot open the webcam, but a fresh local build does not show UI but can open webcam without permissions…

Comment 50

[Jason Smith [:jsmith]]

(In reply to John Drinkwater (:beta) from comment #49)
> (In reply to Jason Smith [:jsmith] from comment #48)
> > On Mac, I'm seeing the camera prompt appearing and allowing me to
> > enable/disable access to the camera/microphone. However, I'm not seeing
> > these prompts at all on windows, which sends the perception that gUM is
> > broken on windows. Dao - Is this working for you on windows?
> 
> Having a similar issue on Linux, Nightly 19.0a1 (2012-10-12) is showing the
> door‐hanger but cannot open the webcam, but a fresh local build does not
> show UI but can open webcam without permissions…

I found out later it was cause I did not correctly enable the preference for gUM (media.navigator.enabled). Works for me now. Can you check that on linux?

Comment 51

[John Drinkwater (:beta)]

(In reply to Jason Smith [:jsmith] from comment #50)
> > Having a similar issue on Linux, Nightly 19.0a1 (2012-10-12) is showing the
> > door‐hanger but cannot open the webcam, but a fresh local build does not
> > show UI but can open webcam without permissions…
> 
> I found out later it was cause I did not correctly enable the preference for
> gUM (media.navigator.enabled). Works for me now. Can you check that on linux?

I had explicitly set media.navigator.enabled & media.peerconnection.enabled to true. Unless its disabled in debug builds, I cannot see why it would not show.

Comment 52

[Jason Smith [:jsmith]]

Finished off a test run on this feature. A good amount of followups to get you started. Blockers with [blocking-gum+] in the whiteboard need to be fixed in FF 19 in order to ship on time for the feature. Marking as verified for now to indicate that testing this feature for an initial test pass is finished.

Note - There will likely be followups for the UX here from privacy team, so stay tuned.

Comment 53

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Some tests which interact with the various ui elements would be good to have.