Closed
Bug 802421
Opened 12 years ago
Closed 12 years ago
Cannot specify a mic and a camera when audio and video are both requested through gUM in the doorhanger UI
Categories
(Firefox :: Site Permissions, defect)
Firefox
Site Permissions
Tracking
()
VERIFIED
FIXED
Firefox 20
People
(Reporter: jsmith, Assigned: dao)
References
Details
(Whiteboard: [getUserMedia] [blocking-gum+])
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
Gavin
:
review+
|
Details | Diff | Splinter Review |
The current design of the doorhanger UI in gUM for permissions does not allow you to select a specific camera you want to use and a specific mic you want to use if you have more than one webcam input source and more than one mic input source. We should allow the user to explicitly define exactly which mic and video they intend to use when both audio and video are requested through gUM.
Reporter | ||
Comment 1•12 years ago
|
||
We need to make sure in this bug that we handle the error case as well if a user specifies a mic, but fails to specify a camera, then an error should be indicated saying that both need to be specified.
Reporter | ||
Updated•12 years ago
|
Whiteboard: [getUserMedia] → [getUserMedia] [blocking-gum+]
Comment 3•12 years ago
|
||
Not blocking for preffing on - a "would be nice"
Assignee: nobody → dao
Whiteboard: [getUserMedia] [blocking-gum+] → [getUserMedia] [blocking-gum-]
Comment 4•12 years ago
|
||
To be more clear: being able to select both is a blocker (resetting). Being able to have two separate dropdowns for mic and camera is a non-blocker, though "would be nice".
Whiteboard: [getUserMedia] [blocking-gum-] → [getUserMedia] [blocking-gum+]
Assignee | ||
Comment 5•12 years ago
|
||
Randell, I'm sending getUserMedia:response:allow twice in order to specify a video device and an audio device. Will the back-end handle this? If not, what API should I use?
Flags: needinfo?(rjesup)
Comment 6•12 years ago
|
||
Well, not it won't work. I'm figuring out what's possible.
Flags: needinfo?(rjesup)
Comment 7•12 years ago
|
||
Probably the best way is to return an array of devices, instead of a single device. While we could return a device for the single case and an array if it's audio+video, it's probably simpler to always return an array.
Assignee | ||
Comment 8•12 years ago
|
||
(In reply to Randell Jesup [:jesup] from comment #7)
> Probably the best way is to return an array of devices, instead of a single
> device. While we could return a device for the single case and an array if
> it's audio+video, it's probably simpler to always return an array.
done, and filed bug 823453
Attachment #693869 -
Attachment is obsolete: true
Comment 9•12 years ago
|
||
bug 823453 is up for review, and tested with this patch and appears to work, so are we ready to review on this?
Assignee | ||
Comment 10•12 years ago
|
||
Attachment #694292 -
Attachment is obsolete: true
Attachment #694407 -
Flags: review?(gavin.sharp)
Comment 11•12 years ago
|
||
Comment on attachment 694407 [details] [diff] [review]
patch
>diff --git a/browser/locales/en-US/chrome/browser/browser.properties b/browser/locales/en-US/chrome/browser/browser.properties
>+# LOCALIZATION NOTE (getUserMedia.shareSelectedDevices.label):
>+# Semi-colon list of plural forms. See:
>+# http://developer.mozilla.org/en/docs/Localization_and_Plurals
It may be worth mentioning that only the "1" and "2" cases need to be handled, but...
>+getUserMedia.shareSelectedDevices.label = Share Selected Device;Share Selected Devices
Using the more generic string all of the time is simpler, but having the button label not match the message text is kind of a UX regression. Are these button string changes really necessary? Why not stick with the existing strings?
Attachment #694407 -
Flags: review?(gavin.sharp) → review+
Assignee | ||
Comment 12•12 years ago
|
||
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #11)
> Comment on attachment 694407 [details] [diff] [review]
> patch
>
> >diff --git a/browser/locales/en-US/chrome/browser/browser.properties b/browser/locales/en-US/chrome/browser/browser.properties
>
> >+# LOCALIZATION NOTE (getUserMedia.shareSelectedDevices.label):
> >+# Semi-colon list of plural forms. See:
> >+# http://developer.mozilla.org/en/docs/Localization_and_Plurals
>
> It may be worth mentioning that only the "1" and "2" cases need to be
> handled, but...
>
> >+getUserMedia.shareSelectedDevices.label = Share Selected Device;Share Selected Devices
>
> Using the more generic string all of the time is simpler, but having the
> button label not match the message text is kind of a UX regression. Are
> these button string changes really necessary? Why not stick with the
> existing strings?
A followup bug to this one would be adding No Video / No Audio options to the dropdowns when both video and audio are requested. It would be strange to have a camera but no mic selected and have the button say "Share Camera and Microphone".
Comment 13•12 years ago
|
||
Ah, I had assumed that we would not handle allowing the user to accept sharing a combination of devices other than what the site requested (and that we would avoid prompting if any of the requested devices were not available). I guess that's not the case?
Assignee | ||
Comment 14•12 years ago
|
||
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #13)
> Ah, I had assumed that we would not handle allowing the user to accept
> sharing a combination of devices other than what the site requested (and
> that we would avoid prompting if any of the requested devices were not
> available). I guess that's not the case?
If both video and audio are requested and either is unavailable, will still show the UI for sharing the other.
Assignee | ||
Comment 15•12 years ago
|
||
Keywords: uiwanted
Comment 16•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 20
Reporter | ||
Comment 17•12 years ago
|
||
Verified by trying some combinations with multiple mics and cameras - sanity level looks okay. 1/29 build.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Updated•10 years ago
|
Component: General → Device Permissions
You need to log in
before you can comment on or make changes to this bug.
Description
•