Open
Bug 1685232
Opened 5 years ago
Updated 8 months ago
[meta] Set media.getusermedia.audiocapture.enabled by default
Categories
(Core :: WebRTC: Audio/Video, enhancement)
Core
WebRTC: Audio/Video
Tracking
()
NEW
People
(Reporter: karlt, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: meta)
Attachments
(1 file)
213.12 KB,
image/png
|
Details |
Dependencies track work remaining.
Updated•5 years ago
|
Summary: Set media.getusermedia.audiocapture.enabled by default → [meta] Set media.getusermedia.audiocapture.enabled by default
Updated•4 years ago
|
Blocks: audio-sharing
![]() |
||
Updated•4 years ago
|
Blocks: tab-sharing
Updated•3 years ago
|
No longer blocks: tab-sharing
Comment 1•3 years ago
|
||
At the moment, this pref controls both underlying tech we need for bug 1541425 and a non-standard API+UX we don't want to ship ever:
- Through a non-standard API (bug 1557174), it allows audio-only capture of the same tab after this prompt: "Allow jsfiddle.net to listen to this tab's audio?". It works but isn't terribly useful.
- If we ask for both video and audio capture, it prompts "Allow jsfiddle.net to listen to this tab's audio and see your screen?" (image), and then always fails with NotAllowedError. The prompt makes no sense as users instead want audio from the tab they pick to share.
Instead we want to implement bug 1541425 comment 13 with its own UX where audio is optional.
Regarding the media.getusermedia.audiocapture.enabled
pref, we should either:
- change it to instead expose the audio feature in getDisplayMedia (bug 1541425), or
- never turn this pref on, and add a new (differently named) pref to expose audio in getDisplayMedia (bug 1541425).
![]() |
||
Updated•2 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•