Closed
Bug 1456899
Opened 3 years ago
Closed 3 years ago
Can't add exceptions for global microphone and camera permission
Categories
(Firefox :: Site Permissions, defect, P3)
Tracking
()
RESOLVED
FIXED
Firefox 62
| Tracking | Status | |
|---|---|---|
| firefox62 | --- | fixed |
People
(Reporter: u616541, Assigned: johannh)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0 Build ID: 20180323154952 Steps to reproduce: In "Privacy & Security" under "Permissions" in Microphone Settings, check the box for "Block new requests asking to access your microphone" and add an exception for "https://hangouts.google.com/". Actual results: When receiving a call or making a call through Hangouts on "https://hangouts.google.com/". The orange microphone icon will not be displayed and the microphone is not active despite appearing as the set device in Hangouts' settings. Expected results: The orange Firefox orange microphone icon should appear and my microphone should be active, allowing me to talk when receiving or making calls.
Updated•3 years ago
|
Has STR: --- → yes
Component: Untriaged → Device Permissions
| Assignee | ||
Comment 1•3 years ago
|
||
Yeah, I can reproduce it even on https://permission.site/, while geolocation and notifications work correctly. This might have never worked for cam/mic because the WebRTC permissions code is completely separate. I can take a look at this.
Assignee: nobody → jhofmann
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: -- → P3
Summary: Microphone permissions exception does not work on hangouts. → Can't add exceptions for global microphone and camera permission
| Assignee | ||
Comment 2•3 years ago
|
||
https://treeherder.mozilla.org/#/jobs?repo=try&revision=3c862057f4182972fedcdf181bf4fe1a74cb7be6
| Comment hidden (mozreview-request) |
Comment 4•3 years ago
|
||
| mozreview-review | ||
Comment on attachment 8974012 [details] Bug 1456899 - Consider the page URI when checking WebRTC permissions in webrtcUI.jsm. https://reviewboard.mozilla.org/r/242344/#review249474 Thanks for the tests :) ::: browser/base/content/test/webrtc/browser_devices_get_user_media_default_permissions.js:22 (Diff revision 1) > + > + // Requesting audio+video shouldn't work. > + let promise = promiseMessage(permissionError); > + await promiseRequestDevice(true, true); > + await promise; > + await expectObserverCalled("recording-window-ended"); Here and elsewhere in the test file, could you double-check (or confirm that you already did :P) that this is okay to await directly without storing the promise beforehand promiseRequestDevice? ::: browser/base/content/test/webrtc/head.js:117 (Diff revision 1) > > let windows = Services.wm.getEnumerator("navigator:browser"); > while (windows.hasMoreElements()) { > let win = windows.getNext(); > let menu = win.document.getElementById("tabSharingMenu"); > - is(menu && !menu.hidden, !!expected, "WebRTC menu should be " + expectedState); > + is(!!menu && !menu.hidden, !!expected, "WebRTC menu should be " + expectedState); Heh, took me a minute to get a clue at what is going on here. JavaScript!!
Attachment #8974012 -
Flags: review?(nhnt11) → review+
| Assignee | ||
Comment 5•3 years ago
|
||
| mozreview-review-reply | ||
Comment on attachment 8974012 [details] Bug 1456899 - Consider the page URI when checking WebRTC permissions in webrtcUI.jsm. https://reviewboard.mozilla.org/r/242344/#review249474 > Here and elsewhere in the test file, could you double-check (or confirm that you already did :P) that this is okay to await directly without storing the promise beforehand promiseRequestDevice? We do this in basically all webrtc tests, so I think we're good :)
Pushed by jhofmann@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/364d47ff7a91 Consider the page URI when checking WebRTC permissions in webrtcUI.jsm. r=nhnt11
Comment 7•3 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/364d47ff7a91
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox62:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 62
You need to log in
before you can comment on or make changes to this bug.
Description
•