Closed Bug 1363854 Opened 3 years ago Closed 1 year ago
I want to be able to use get
User Media in a 'Popup' window
When I try to access getUserMedia from inside a popup, I am getting the following CSP error . The reason we need to use gUM from a popup and not from a tab is because we are prototyping a speech enabled virtual assistant that should be accessible anywhere in the browser, just a click away, to achieve the same experience we have on MacOS, when you just click a small icon in the toolbar to activate Siri, or on Windows to activate Cortana.  Content Security Policy: The page’s settings blocked the loading of a resource at self (“script-src moz-extension://3aaf0592-e6d0-6845-b325-6d6ed234b1b7”). Source: navigator.getUserMedia = navigator.ge....
I'm not sure about the CSP error but the basic issue here is that calling gUM generates a permission prompt which requires that the request come from within a tabbrowser. A popup doesn't have one of course. For things like geolocation and peristent indexedDB we have used permissions in the extension manifest (or granted through the optional permissions API) in lieu of an interactive prompt). We could consider doing the same for gUM. Chrome apparently did this for apps with "audioCapture" and "videoCapture" permissions. Caitlin, can you put this on the agenda for a future api triage?
Thanks, Andrew! It's been added to the agenda. Andre, would you be able to join us at the meeting? Wiki: https://wiki.mozilla.org/Add-ons/Contribute/Triage#Next_Meeting Agenda: https://docs.google.com/document/d/1vrhHNOelBty4hXcjQ8VbFk-azHRFFDVyGka7H0VpEa8/edit#
(In reply to Caitlin Neiman (http://pronoun.is/she) from comment #2) > Thanks, Andrew! It's been added to the agenda. Andre, would you be able to > join us at the meeting? > Hi Caitlin. Sure, I will be there! Thank you both for the attention on this matter!
We'll need some UX help on this one. We could do this through installation permissions, or maybe optional permissions, but there's a real concern that recording audio or video needs to give the user some kind of feedback that this is happening right now. It would be pretty easy to install an add-on, approve this permission then forget about it. Currently if a web page is doing audio or video capture, then it shows up on the tab. In this case there would be no tab to show an icon or indication to the user. This could be from a browser popup or a background page. We'd need a firmer idea what to do for UX here before we approve this one, but we don't want to deny it either we think there's a good use case here.
Flags: needinfo?(amckay) → needinfo?(mjaritz)
I agree that we should ensure the user can be aware of audio &/or video capture being active, and has the control to stop them. And that, at least once, the user has to allow it, and be able to decide if they permanently allow this. (As we do with websites.) As it looks like we will continue expanding what extensions can do and in what contexts, I think therefor this is a policy questions first. Do we treat extensions same as websites, or in what cases is it OK to have less control as a user? We are starting to look into managing extensions and themes in Firefox more deeply, and with that all the individual ways they influence Firefox will be looked at. (permissions, optional permissions, overrides, web/tab permissions). I hope this will lead to a policy on when to show what to the users, and have a framework that provides UI for such additional requests. With our current UI this does not look like an easy thing to solve. (And just listing it as a permission on install does not sound right.) Maybe asking the users for permission to do recordings through a tab, and have them set that permission to permanent might be a first steps that can ensure that the user is aware of what will happen. (Assuming that granted permission can then also be used in a pop-up/background process...)
Based on the feedback, I'm going to mark this as approved, with the caveat that whomever decides to take on this bug needs to start by working on the UX problems first.
Priority: -- → P5
Whiteboard: design-decision-needed → design-decision-approved
Hey Andy, I can take it.
(In reply to Markus Jaritz [:designakt] (UX) from comment #5) > As it looks like we will continue expanding what extensions can do and in > what contexts, > I think therefor this is a policy questions first. > Do we treat extensions same as websites, or in what cases is it OK to have > less control as a user? Markus, I would like to circle back to this since your last comments came a year ago and a lot has changed in that time. The ability to use gUM from an extension popup or background script still has valid use cases, but also comes with valid UX, security and privacy concerns. Has anything come along that might make this easier to implement?
(In reply to Mike Conca [:mconca] (Denver, CO, USA UTC-6) from comment #8) > > Markus, I would like to circle back to this since your last comments came a > year ago and a lot has changed in that time. The ability to use gUM from an > extension popup or background script still has valid use cases, but also > comes with valid UX, security and privacy concerns. Has anything come along > that might make this easier to implement? I am not aware of any policy decisions or guidelines of how we should balance user control with ease of use for extensions. So I would assume we have to still take highest precautions to ensure that the user is aware of the recording. And this means we have to show the permission dialog, as we do on websites... and this requires a tab, or maybe we could re-use that dialog and hang it off of an extensions icon. (But for extensions without icon, I worry that this is getting confusing... we already have a few cases where we show a dialog attached to the Firefox menu, instead of the extension icon - but this should not scale to more and more cases.) (Maybe it is time to consider requiring an icon in the toolbar/overflow for every extensions... as this would make it more transparent what permission connects with what extension) Possibly something to discuss in our meeting today.
1 year ago
Status: NEW → RESOLVED
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.