Note: There are a few cases of duplicates in user autocompletion which are being worked on.

Implement WebRTC navigator.getUserMedia() user interface

VERIFIED FIXED in Firefox 18

Status

()

Firefox
Device Permissions
VERIFIED FIXED
6 years ago
3 years ago

People

(Reporter: jesup, Assigned: dao)

Tracking

(Depends on: 2 bugs, Blocks: 1 bug)

unspecified
Firefox 18
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(3 attachments, 11 obsolete attachments)

(Reporter)

Description

6 years ago
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).
Randell, can you add a link to the mockups?
(Reporter)

Comment 2

6 years ago
http://new.tinygrab.com/08092efbdd03a3bafe1718fcf0c0bbd6a75aa30e37.jpg
(Reporter)

Updated

6 years ago
Blocks: 729593

Comment 3

6 years ago
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.

Updated

5 years ago
OS: Linux → All
Hardware: x86_64 → All

Updated

5 years ago
Whiteboard: [getUserMedia]

Updated

5 years ago
Whiteboard: [getUserMedia] → [getUserMedia], [blocking-gum+]

Updated

5 years ago
No longer blocks: 729593
Duplicate of this bug: 729593
Created attachment 664949 [details]
gUM UX design - first iteration

If anyone in addition to Boriss is needed for the UI review, please add them.
Attachment #664949 - Flags: ui-review?(jboriss)
(Assignee)

Comment 6

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

Comment 8

5 years ago
Yes, in fact you might want to spin it off to a separate bug.
Just so this doesn't get lost -- quick attempt by shorlander of an Australis friendly version:
http://cl.ly/image/0l0H2z2H0w0o
Just so this doesn't get lost -- quick attempt by shorlander of an Australis friendly version:
http://cl.ly/image/0l0H2z2H0w0o
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?

Updated

5 years ago
QA Contact: jsmith
(Assignee)

Comment 12

5 years ago
Created attachment 665866 [details] [diff] [review]
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?)
(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.
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!
(Assignee)

Comment 15

5 years ago
(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.
Created attachment 666072 [details]
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.
Attachment #664949 - Attachment is obsolete: true
Attachment #664949 - Flags: ui-review?(jboriss)
(Assignee)

Comment 17

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

Comment 19

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

Comment 20

5 years ago
Created attachment 666955 [details] [diff] [review]
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.
Attachment #665866 - Attachment is obsolete: true
Created attachment 667801 [details] [diff] [review]
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.
Attachment #666955 - Attachment is obsolete: true
Attachment #667801 - Flags: review?(dolske)
Attachment #667801 - Flags: feedback?(dao)
Created attachment 667805 [details] [diff] [review]
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 :)
Attachment #667805 - Flags: review?(rjesup)
Created attachment 667810 [details] [diff] [review]
Part 2: Hookup gUM backend with the UI

Forgot to not ask permission when called from privileged code!
Attachment #667805 - Attachment is obsolete: true
Attachment #667805 - Flags: review?(rjesup)
Attachment #667810 - Flags: review?(rjesup)
(Assignee)

Comment 24

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

Updated

5 years ago
Depends on: 797796
(Assignee)

Comment 25

5 years ago
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.
Attachment #667810 - Attachment is obsolete: true
Attachment #667810 - Flags: review?(rjesup)
(Reporter)

Comment 26

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

Comment 27

5 years ago
Created attachment 667891 [details] [diff] [review]
WIP patch v4
Assignee: nobody → dao
Attachment #667801 - Attachment is obsolete: true
Attachment #667801 - Flags: review?(dolske)
Attachment #667801 - Flags: feedback?(dao)
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!
(Assignee)

Comment 29

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

Comment 30

5 years ago
Created attachment 668101 [details] [diff] [review]
WIP patch v5

entirely untested, waiting for bug 797796
Attachment #667891 - Attachment is obsolete: true
(Assignee)

Comment 31

5 years ago
Created attachment 668103 [details] [diff] [review]
WIP patch v5

uploaded the wrong patch...
Attachment #668101 - Attachment is obsolete: true
Uploaded a patch to bug 797796, you can run a test at https://people.mozilla.com/~anarayanan/gum_test.html
(Assignee)

Comment 33

5 years ago
Created attachment 668121 [details] [diff] [review]
WIP patch v6
Attachment #668103 - Attachment is obsolete: true
(Assignee)

Comment 34

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

Comment 35

5 years ago
Created attachment 668172 [details] [diff] [review]
patch

The patch in bug 797796 currently sends the inner window's ID. With that changed to the outer window's ID, things work.
Attachment #668121 - Attachment is obsolete: true
Attachment #668172 - Flags: review?(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)
Attachment #668172 - Flags: review?(dolske) → review+
(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.
(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
(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.
(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?
(Assignee)

Comment 41

5 years ago
Created attachment 668375 [details] [diff] [review]
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
Attachment #668172 - Attachment is obsolete: true
(Reporter)

Comment 42

5 years ago
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 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/anarayanan@mozilla.com-5a87868ad982)

Alternatively, I could take screenshots for what the UI looks like in practice, if that's easier for you.
Attachment #668375 - Flags: ui-review?(jboriss)
Created attachment 668398 [details]
Permission dialog on Linux

For reference, this is what the implemented UI looks like on Linux, with a single camera, when video is requested.
Let's try try again: https://tbpl.mozilla.org/?tree=Try&rev=2dfe70dfcef1
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/anarayanan@mozilla.com-2dfe70dfcef1
(Assignee)

Updated

5 years ago
Depends on: 798336
Attachment #668375 - Flags: ui-review?(jboriss) → ui-review+
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
https://hg.mozilla.org/mozilla-central/rev/b9de5da14ab0
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18

Updated

5 years ago
Keywords: verifyme
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?
(Assignee)

Updated

5 years ago
Blocks: 799415
(Assignee)

Updated

5 years ago
Depends on: 799417

Updated

5 years ago
Depends on: 801066

Updated

5 years ago
Depends on: 801068
(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…
(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?
(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.

Updated

5 years ago
Depends on: 802397

Updated

5 years ago
Depends on: 802399

Updated

5 years ago
Depends on: 802416

Updated

5 years ago
Depends on: 802419

Updated

5 years ago
Depends on: 802421
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.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Some tests which interact with the various ui elements would be good to have.
Flags: in-testsuite?

Updated

5 years ago
Depends on: 804611
Depends on: 809085
Depends on: 829901
(Assignee)

Updated

5 years ago
No longer depends on: 829901
Depends on: 921004
Component: General → Device Permissions
You need to log in before you can comment on or make changes to this bug.