1456899 - Can't add exceptions for global microphone and camera permission

Status: RESOLVED FIXED

(Firefox :: Site Permissions, defect, P3)

Description

[u616541]

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.

Comment 1

[Johann Hofmann [:johannh]]

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.

Comment 2

[Johann Hofmann [:johannh]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3c862057f4182972fedcdf181bf4fe1a74cb7be6

Comment 3

[Johann Hofmann [:johannh]]

Attachment: Bug 1456899 - Consider the page URI when checking WebRTC permissions in webrtcUI.jsm.

While we already do a permission check in native webrtc code, the one
in webrtcUI is needed to provide extra protection against permission spam
by checking if there's a temporarily denied permission on the tab.

Since we introduced custom default permission values it is necessary to
also pass the URI to make sure we catch exceptions added by the user.

Review commit: https://reviewboard.mozilla.org/r/242344/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/242344/

Comment 4

[(inactive) Nihanth Subramanya [:nhnt11]]

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!!

Comment 5

[Johann Hofmann [:johannh]]

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 :)

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/364d47ff7a91
Consider the page URI when checking WebRTC permissions in webrtcUI.jsm. r=nhnt11

Comment 7

[Eliza Balazs [:ebalazs_]]

https://hg.mozilla.org/mozilla-central/rev/364d47ff7a91