Closed Bug 1278100 Opened 4 years ago Closed 1 year ago

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


(WebExtensions :: General, defect, P3)

49 Branch


(Not tracked)



(Reporter: noitidart, Unassigned)



(Whiteboard: webrtc, optional permissions, triaged)

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 -

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 -

And demonstrated here -

From classic bootstrap I request access to the mic from Services.appShell.hiddenDOMWindow and I get access without user prompt.
Component: Untriaged → General
OS: Unspecified → All
Hardware: Unspecified → All
Component: General → WebExtensions
Product: Firefox → Toolkit
Version: 47 Branch → 49 Branch
Depends on: 1197420
Priority: -- → P3
Whiteboard: webrtc, optional permissions, triaged
Duplicate of this bug: 1296954
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:
Are we going to allow background page to use mic after initial access was granted? Chrome currently does allow it -
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.
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.
See Also: → 1394062
Duplicate of this bug: 1398083
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.
Any news on this issue? Is there any way we can help resolve this issue? We are currently working on a softphone webextension ( 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).

In general, the feeling has been that extensions should only have WebRTC access from visible tabs, which users can see and control.
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?
Blocks: 1303919
Product: Toolkit → WebExtensions
Does this issue have any priority yet? We are about to release an opensource WebRTC softphone( to the public, and would like to include Firefox support. This is the only ticket that blocks us from doing so.
Bulk move of bugs per
Component: Untriaged → General
Duplicate of this bug: 1398083

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

Closed: 1 year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1579489
You need to log in before you can comment on or make changes to this bug.