3 ms·

Pretty much this. The code runs as an extension - it registers the protocol handler in the extension's background script. That means the code for webrtc has no

Pretty much this. The code runs as an extension - it registers the protocol handler in the extension's background script. That means the code for webrtc has no need to run in a service worker.

saurik 6y ago
OK, so as I don't actually do much in-browser development, and because this was also two years ago, "of course" I managed to get the terminology wrong: the issue was that WebRTC wasn't supported in a "WebExtension" (not a "service worker", which happened to be the subject of a massive thread I was reading a few weeks ago on WebRTC not working there either). Here's the bug I had referred to the libdweb person at the time in November of 2018 (due to comment #2): > RTCPeerConnection.createOffer doesn nothing in WebExtension background script https://bugzilla.mozilla.org/show_bug.cgi?id=1398083 https://bugzilla.mozilla.org/show_bug.cgi?id=1398083 This bug had already been resolved in September of 2018 as a duplicate of this bug: > WebExtension cannot access WebRTC mic from popup.js nor background.js https://bugzilla.mozilla.org/show_bug.cgi?id=1278100 https://bugzilla.mozilla.org/show_bug.cgi?id=1278100 And I now see that bug ended up getting resolved in September of 2019 as a duplicate of this bug: > Improve getUserMedia permission model for web extensions a bit. https://bugzilla.mozilla.org/show_bug.cgi?id=1579489 https://bugzilla.mozilla.org/show_bug.cgi?id=1579489 Which was supposedly fixed? I'm honestly a bit concerned still, though, as this bug slowly got dragged from being about createOffer to being about permissions dialogs for audio/video, and it kind of sounds like there's some weird thing where a "foreground page" has to vouch for the extension, which shouldn't be required. Everyone who works on WebRTC stuff in browsers conflates it all with getUserMedia, but all of us distributed web people just want peer-to-peer data channels :/. I take it this is actually fixed then, and you can now use WebRTC in this context?

Pretty much this. The code runs as an extension - it registers the protocol handler in the extension's background script. That means the code for webrtc has no need to run in a service worker.

saurik 6y ago

OK, so as I don't actually do much in-browser development, and because this was also two years ago, "of course" I managed to get the terminology wrong: the issue was that WebRTC wasn't supported in a "WebExtension" (not a "service worker", which happened to be the subject of a massive thread I was reading a few weeks ago on WebRTC not working there either). Here's the bug I had referred to the libdweb person at the time in November of 2018 (due to comment #2): > RTCPeerConnection.createOffer doesn nothing in WebExtension background script https://bugzilla.mozilla.org/show_bug.cgi?id=1398083 https://bugzilla.mozilla.org/show_bug.cgi?id=1398083 This bug had already been resolved in September of 2018 as a duplicate of this bug: > WebExtension cannot access WebRTC mic from popup.js nor background.js https://bugzilla.mozilla.org/show_bug.cgi?id=1278100 https://bugzilla.mozilla.org/show_bug.cgi?id=1278100 And I now see that bug ended up getting resolved in September of 2019 as a duplicate of this bug: > Improve getUserMedia permission model for web extensions a bit. https://bugzilla.mozilla.org/show_bug.cgi?id=1579489 https://bugzilla.mozilla.org/show_bug.cgi?id=1579489 Which was supposedly fixed? I'm honestly a bit concerned still, though, as this bug slowly got dragged from being about createOffer to being about permissions dialogs for audio/video, and it kind of sounds like there's some weird thing where a "foreground page" has to vouch for the extension, which shouldn't be required. Everyone who works on WebRTC stuff in browsers conflates it all with getUserMedia, but all of us distributed web people just want peer-to-peer data channels :/. I take it this is actually fixed then, and you can now use WebRTC in this context?