1398083 - RTCPeerConnection.createOffer doesn nothing in WebExtension background script

Status: RESOLVED DUPLICATE of bug 1278100

(WebExtensions :: General, defect)

Description

[uniemperor]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170816210634

Steps to reproduce:

I was trying to stream UserMedia from a WebExtension created tab to a background script, which would've started a call through WebRTC.

I tried the following in the background script:
let pc = new RTCPeerConnection({ iceServers: [] });
pc.createOffer({
        offerToReceiveAudio: true,
        offerToReceiveVideo: true,
    }).then(offer => {
        // initiate handshake through port.postMessage, receive stream, etc...
});


Actual results:

Nothing happened. No error thrown, and the offer wasn't created.
Tried it with the old syntax as well, with the success and error callbacks. Same result.


Expected results:

Either the offer should have been created or an error thrown due to lack of privileges.

While this works in Chrome, I don't know what Firefox's policy is on WebRTC in the background.

The problem exists in Firefox 55, 56, and nightlies as well.

Comment 2

[Rob Wu [:robwu]]

Re-opening because I encountered this issue, and found ways to fix it (see bottom of this comment), while the fix does not solve bug 1278100.

Original test case:
1. Open an extension's background page.
2. Copy-paste the snippet from https://stackoverflow.com/a/29514292 and change "document.body.textContent = "..." to console.log("...").

Expected:
- Local IP addresses are printed.

Actual:
- Nothing happens.


Minimal test case:
1. Open an extension's background page
2. Run:
new RTCPeerConnection().createOffer(console.log,console.error)

Expected:
- DOMException [InternalError: "Cannot create an offer with no local tracks, no offerToReceiveAudio/Video, and no DataChannel." ...

Actual:
- Promise never resolves.


While debugging I found that the parent message handler processes rtcpeer:Request and sends rtcpeer:Allow in response to the request (webRTCUI.jsm [2]), but that there are no handlers in the content because the frame script that registers the WebRTC message handler [1] is not loaded for background pages.

As a quick prototype, I added the following snippet to [3], and my manual test case succeeded:
aMessage.target.messageManager.loadFrameScript("chrome://browser/content/content.js", false);

Extension popups are not affected by this bug because the content.js frame script is loaded in [4].
There are multiple ways to fix the bug, depending on the answer to the following questions:
- Do we want to load content.js to fix this bug, or just the WebRTC message logic of that frame script?
- Do we want to apply the fix to every extension global (at the _onExtensionBrowser handler in ExtensionParent.jsm [5]), or only for the background page (in [6]).


[1] https://searchfox.org/mozilla-central/rev/7fb4cc447c06f14fe3b5c6b0c9d103a860937250/browser/base/content/content.js#680-688
[2] https://searchfox.org/mozilla-central/rev/7fb4cc447c06f14fe3b5c6b0c9d103a860937250/browser/modules/webrtcUI.jsm#208-241
[3] https://searchfox.org/mozilla-central/rev/7fb4cc447c06f14fe3b5c6b0c9d103a860937250/browser/modules/webrtcUI.jsm#237
[4] https://searchfox.org/mozilla-central/rev/7fb4cc447c06f14fe3b5c6b0c9d103a860937250/browser/components/extensions/ExtensionPopups.jsm#299
[5] https://searchfox.org/mozilla-central/rev/7fb4cc447c06f14fe3b5c6b0c9d103a860937250/toolkit/components/extensions/ExtensionParent.jsm#347-364
[6] https://searchfox.org/mozilla-central/rev/7fb4cc447c06f14fe3b5c6b0c9d103a860937250/toolkit/components/extensions/ext-backgroundPage.js#27-47