twitter-square facebook-square linkedin-square info tag download trakstar-mark

Mindflash is now Learn, part of the new Trakstar Trifecta alongside Hire and Perform

Learn more about how the Trakstar platform is revolutionizing talent management through integrated, flexible solutions.

Trakstar

Handling Chrome's Extra Security for Using the Microphone in Flash

— by David Kaminsky

One of my first projects at Mindflash was to create a feature that gave trainers the ability to record narration over their slides within the Mindflash app. The impetus for this was that content like Word documents and PDFs don't give you the ability to record audio as you're creating them. Thus if you wanted audio over this type of content there needed to be a solution built into Mindflash. Additionally even though PowerPoint includes built-in audio recording, many of our users struggled to figure out how to effectively use it. We provided help articles to educate them on how to use PowerPoint's built-in audio recording feature but many users still struggled. Thus, we sought to make something simple for our users to quickly narrate over their slides. Since adding this feature we've found that 25% of our customers are using it.

We created this functionality in Flash both because our trainer app at the time was written entirely in Flash and also because there wasn't (and still isn't) any way other way for us to add this functionality for all of our supported browsers (back then we supported all the way back to IE8, today we support back to IE9). We spent a lot of time researching and writing up hacks to detect if the user denied the security dialog Flash pops up to ask for permission to use the computer's microphone and perfecting the workflow so that if she did, the app would respond properly to let her know why she couldn't use the recorder. Once she allowed permission through the Flash pop-up everything would become enabled because at this point we have permission from Flash to use the microphone and thus record.

This all worked fantastically on all browsers for a while until Chrome added additional security that forced the user to click “Allow” a second time on a notification they bring up below the address bar. See the screenshot for what it looks like below:

chrome-notification-bar

There is much to gripe about this notification.

  • It's in a location potentially far from where the user clicked to trigger it
  • It blends in with Chrome's address bar so users frequently don't notice it
  • it doesn't show up until after you've tried to start using the mic.

In my opinion the worst problem is that it doesn't appear until after you've tried to start using the mic. With Flash you can ask for permission before you actually turn the mic on so we've set up Mindflash to immediately ask for permission to use the mic as soon as the user opens the audio recorder. This forces the user to determine if they want to allow Flash to have access to their microphone before they're able to take action to start recording. Thus, in any other browser if they clicked the button to record audio we already have their permission and we're able to immediately start recording. However, in Chrome as soon as they click the record button the notification center security setting will come up and nothing will actually start recording until they click “Allow.” This is a much more confusing workflow.

Before we figured out how to better handle this, when this notification center security setting came up the app would continue to assume it had access to the microphone and act as though it was recording. This was with good reason as according to Flash the microphone is actually on (this can be checked by verifying the Microphone object's “muted” property is false) so there was no reason to think we're not recording. However, even though Flash thinks the mic is on it's not actually sending any audio data. This is how we were better able handle Chrome's extra security.

Below is a partial code snippet that shows how we can detect if we're actually getting audio data once we start trying to record.

The idea here is to constantly check the size of the raw audio data. If two seconds after the user hit the record button we still don't have even a negligible amount of audio data then we know we're not actually recording and we'll show the user something to let them know how they can fix this problem. Once they click the Chrome-specific “Allow” button the recorder works as the user would expect, immediately starting to record their audio.

handle-chrome-mic-notification

While I haven't tried it, I'd assume this would work quite similarly for video input. If anyone tries it with video input I'd love to hear how it works so please leave a comment.

Share this on

Who is Trakstar?

Trakstar is a multi-product HR software provider helping organizations put the people back in people management. Develop and align your staff through better recruiting and applicant tracking, performance management, and learning management. For a more integrated solution to talent management, check out our website and request a live demonstration today.