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

UNCONFIRMED
Unassigned

Status

P3
normal
UNCONFIRMED
3 years ago
a month ago

People

(Reporter: noitidart, Unassigned)

Tracking

49 Branch
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: webrtc, optional permissions, triaged)

(Reporter)

Description

3 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.
(Reporter)

Updated

3 years ago
Component: Untriaged → General
OS: Unspecified → All
Hardware: Unspecified → All
(Reporter)

Updated

3 years ago
Component: General → WebExtensions
Product: Firefox → Toolkit
Version: 47 Branch → 49 Branch
Depends on: 1197420

Updated

3 years ago
Priority: -- → P3

Updated

3 years ago
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:
http://searchfox.org/mozilla-central/rev/8071f94c4d4b66833ad08db39565669faad94dfd/dom/base/Navigator.cpp#2136-2142
(Reporter)

Comment 3

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

2 years 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.
(Reporter)

Comment 5

2 years 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.
See Also: → bug 1394062
Duplicate of this bug: 1398083

Comment 8

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

Comment 9

11 months ago
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
In general, the feeling has been that extensions should only have WebRTC access from visible tabs, which users can see and control.

Comment 11

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

Updated

8 months ago
Blocks: 1303919

Updated

8 months ago
Product: Toolkit → WebExtensions

Comment 12

7 months ago
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.
Duplicate of this bug: 1398083

Comment 15

a month ago

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

You need to log in before you can comment on or make changes to this bug.