1278100 - WebExtension cannot access WebRTC mic from popup.js nor background.js

Status: RESOLVED DUPLICATE of bug 1579489

(WebExtensions :: General, defect, P3)

Description

[noitidart]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:47.0) Gecko/20100101 Firefox/47.0
Build ID: 20160602131235

Steps to reproduce:

I created a webextenion seen here - https://github.com/Noitidart/Songifier-Webextension/tree/bea79ed53238c90ce62caddb1241d8f7fbfe105c

This adds a button to the toolbar. The button opens a panel, here we see two buttons "Listen in popup" and "Listen in background".

Each triggers `window.navigator.mediaDevices.getUserMedia({audio: true}).then(....)` in the respective scope.

The goal is to get access to the mic so the user can record.

Clicking "Listen in popup" causes the webrtc permission popup to come up. However clicking "Share" does not do anything, when it should grant and trigger the callback.

Clicking "Listen in background", it tries to show the popup but errors with this message in browser console: "TypeError: stringBundle is undefined     webrtcUI.jsm:303:7"



Expected results:

access should probably be given without prompt from both scopes as this is addon privelaged scope. and this is how it works in classic bootstrap addons as seen here - https://dxr.mozilla.org/mozilla-central/source/browser/modules/webrtcUI.jsm#201

And demonstrated here - https://addons.mozilla.org/en-US/firefox/addon/songifier/

From classic bootstrap I request access to the mic from Services.appShell.hiddenDOMWindow and I get access without user prompt.

Comment 2

[Andrew Swan [:aswan]]

For comparison, in Chrome getUserMedia() is not available in a background page or in a popup.  But it does work from a web_accessible_resource in an actual tab (or frame inside a tab).  I did a quick&dirty test in nightly and this seems to work fine in Firefox.
For what its worth, Chrome has (had?) "audioCapture" and "videoCapture" permissions for apps, but not for extensions.

I think the Chrome behavior is sensible -- when the permission prompt comes up, it is associated with the extension page that the user is actually looking at, which reduces opportunities for confusion.

I propose we do the same and turn this bug into improving the error handling when getUserMedia() is called from an illegal location.  Alternatively, we could add logic here to actually suppress getUserMedia() from even appearing, as Chrome does:
http://searchfox.org/mozilla-central/rev/8071f94c4d4b66833ad08db39565669faad94dfd/dom/base/Navigator.cpp#2136-2142

Comment 3

[noitidart]

Are we going to allow background page to use mic after initial access was granted? Chrome currently does allow it - https://stackoverflow.com/questions/39310304/chrome-extension-microphone-capture

Comment 4

[Andy McKay]

This sounds similar to bug 1363854, maybe even a dupe, which has someone who wants to take it on. The problem here is that we need to be very careful about what we allow an extension to do and message that clearly to the user. Recording audio and video is a sensitive topic.

Comment 5

[noitidart]

Awesome! Thanks for that fast reply! Would be way cool if we can match Chrome. In firefox my users have to leave the tab opened after initial permission. In chrome they can close it out.

Comment 6

[Andy McKay]

See also: https://www.bleepingcomputer.com/news/security/chrome-bug-allows-sites-to-record-audio-and-video-without-a-visual-indicator/

Comment 8

[uniemperor]

As a note on this, WebRTC itself doesn't work in the background page at all, even without asking for UserMedia, you can't receive media either, as RTCPeerConnection.createOffer() doesn't create the offer to begin with.

Comment 9

[Jeroen van Veen]

Any news on this issue? Is there any way we can help resolve this issue? We are currently working on a softphone webextension (https://github.com/voipgrid/vialer-js) and would like to enable calling from Firefox, but the browser doesn't remember the getUserMedia permission for the WebExtension like Chrome does(initially triggered from a tab popout).

Cheers

Comment 10

[Kris Maglione [:kmag]]

In general, the feeling has been that extensions should only have WebRTC access from visible tabs, which users can see and control.

Comment 11

[Jeroen van Veen]

What are the issues with being able to access WebRTC api's from the background script once the user permitted it? Why did Google implement it in another direction? Isn't there some form of standardization on these specific WebExtension parts? Ideally, the getUserMedia permission could be specified in the manifest.json permissions, so a user only has to switch the permission on at install of the WebExtension. Having a clear visual clue that the media is being accessed at some time would maybe be a solution for the user not feeling in control over when and where the webrtc api's are accessed?

Comment 12

[Jeroen van Veen]

Does this issue have any priority yet? We are about to release an opensource WebRTC softphone(https://github.com/vialer/vialer-js) to the public, and would like to include Firefox support. This is the only ticket that blocks us from doing so.

Comment 13

[Firefox Bug Husbandry Bot]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958

Comment 15

[Dan Jenkins]

Any movement on this? I can confirm this is an issue.

Chrome seems to do it right.... you still have to give permission from a foreground page in the extension before the underlying extension background.js is allowed to do "webrtc" which is ideal. Still need to ask for permission from the user but allows the backend JS to make thosewebrtc connections or get access to your microphone stream