bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

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




WebExtensions: Untriaged
2 years ago
6 months ago


(Reporter: noitidart, Unassigned)


49 Branch

Firefox Tracking Flags

(Not tracked)


(Whiteboard: webrtc, optional permissions, triaged)



2 years ago
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.


2 years ago
Component: Untriaged → General
OS: Unspecified → All
Hardware: Unspecified → All


2 years ago
Component: General → WebExtensions
Product: Firefox → Toolkit
Version: 47 Branch → 49 Branch


2 years ago
Priority: -- → P3


2 years ago
Whiteboard: webrtc, optional permissions, triaged
Duplicate of this bug: 1296954

Comment 2

2 years ago
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:

Comment 3

10 months ago
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

10 months ago
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

10 months ago
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.


7 months ago
See Also: → bug 1394062
Duplicate of this bug: 1398083

Comment 8

6 months ago
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.
You need to log in before you can comment on or make changes to this bug.