Currently, forge apps cannot access the user’s microphone, and there’s no way to request that either. I don’t see why that should be, as users are prompted for permission before microphone can be accessed. But right now, we can’t even prompt users for consent.
All it’ll take to change this, is to add the string: allow=“microphone *” to the iframe declaration that loads the forge app.
Could this please be done, at least for this hackathon?
Hi Ali, Sorry I don’t know enough to answer this questions, but as the Codegeist campaign manager, it’s great to see you taking advantage of the community!
If no one has an answer for this, definitely consider submitting it to the Forge Kanban board as an enhancement. And, tag it as #Codegeist. Per the rules on the Devpost site, Forge feedback related to Codegeist will be eligible for a bonus prize.
Thanks @CarrieMamantov - just to clarify, I want to build a project that takes voice commands using your mic - but currently forge apps can’t ask for access to user’s mic.
However, using Google Chrome’s developer tools, I can give myself mic permission, on my own machine.
Is it ok to build & submit my project, using this method as a workaround while a proper way to request mic access is worked on?
I’m looking to get an official answer on this.
In the meantime, have you considered this workaround that was previously shared: New sandboxing of Connect App Iframes in Confluence and Jira - #68 by sven.schatter Curious whether that would work in your case.
@bentley That workaround requires access to window.open which is blocked in Forge: Forge - window.open(url, _blank) - blocked
Couldn’t you use router.open? https://developer.atlassian.com/platform/forge/custom-ui-bridge/router/#open
We’re OK with this being submitted with the workaround.
Our thinking on it is: because submissions are judged based on creativity within the boundaries that we’ve specified (namely building on Forge) and the elegance of the solution, your app could get a 
for creativity and a 
for user experience/elegance of solution. That doesn’t mean that it is a net negative or positive (I’m also not a judge 
) but something for you to weigh before deciding to submit.
Hey @bentley ,
Appreciate the response!
However, IMO, the user experience being bad shouldn’t be a negative from a judging standpoint. The workaround should just be seen as temporary until Forge provides a way to request mic permissions in the manifest file, IMO.
In such I would open a separate web page which does not have access to Jira/Confluence anymore.
That workaround works in Atlassian Connect, because I can still communicate with that new page.
If you wanted to make an extension which saves a video recording to Confluence(an example idea) - that’s not possible in Forge.
Ideally we should be able access mic/camera/fullscreen/screenshare from Forge, Connect apps. I’m yet to hear a reason why it is blocked. 
Looks like there is an issue for it already which means it is on the team’s radar 
: Log in with Atlassian account
Pushing further down this route (this is a bit out there, but curious to see if we can’t find some workaround, albeit not the ideal 
).
Could you generate some sort of auth jwt server-side in Forge (via a resolver) as well as a webtrigger URL (https://developer.atlassian.com/platform/forge/runtime-reference/web-trigger-api/) and pass both along to the router.open call as a query params. And then on the page that gets opened, collect whatever microphone data you need to, and then post it back to the webtrigger URL that you have access to. So instead of the normal flow of talking back to window.opener from the opened window, you keep moving the data forward and eventually end up back in your Forge app?
Again, this is a heck of a lot of work to just get access to the microphone but curious if it could work.
@bentley If I had to go that route, I’d want to use websockets so the user sees the app reacting pretty quickly as they speak - if they have to wait on webhooks etc, that defeats the whole point of doing things via voice instead of clicks. If voice takes longer than clicking to do things manually - they’d rather do things manually.
Were you able to get any info re websockets, perhaps via the inner iframe workaround?
Sounds like it could work 
The question is if it is compatible with the spirit of Atlassian Forge: no data egress.
Hahaha, that’s one hell of a workaround. I will refrain from commenting on the maturity of the forge framework to keep the conversation light 
router.open shows an ugly popup warning for any external URL. Forge team seemed to have gone so hard on locking down the security that it’s severely limited the scope of what can be built on the platform.
Hey Team,
Dan, Engineering Manager from Forge here. I’m currently getting some eyes on this work and hope to have an update soon.
Hey Team,
While I can’t make any guarantees here, we are hoping for this change to reach Jira and Confluence production in the coming days. This is the best case, although it can take weeks. There are many variables, but know that we’re on it 
That’s great news, thank you @danielwinterw . My UI has a mic icon and I’m hoping to be able to make it functional for my submission…
Since integrating voice recognition will take a few days too, perhaps a really rough early version could be released soon? Perhaps something limited only to dev apps until more testing is done?
Either way, thank you for trying
@aliakhtar this is more about our release pipeline rather than dev time. We can’t do much to get this out earlier, unfortunately.
Hey All
Both Camera and Mic access should now be available in Jira production. We are still waiting for Confluence. Will provide further updates when it goes live.
That was quick, thanks for the update!