User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:79.0) Gecko/20100101 Firefox/79.0

Steps to reproduce:

Platform: macOS
Firefox Nightly Version: 79.0a1
Steps:
Go to about:support

Actual results:

Troubleshooting Information Page Open , then get prompted for Microphone access

Expected results:

Troubleshooting Information Page Open

Not an exploitable security issue so no need to keep this hidden.

Paul, can we avoid prompting for OS permission just to get the audio roundtrip info?

No, we need to open a real stream on macOS.

I don't know if we can inspect microphone OS permissions from Gecko and only do this if allowed? And maybe put a button that makes it a bit more explicit? Jan-Ivar, do you know?

I'll disable this in non-nightly for the time being.

(In reply to Paul Adenot (:padenot) from comment #2)

I don't know if we can inspect microphone OS permissions from Gecko and only do this if allowed? And maybe put a button that makes it a bit more explicit? Jan-Ivar, do you know?

We can, and the patch to do this is trivial, I'll do this.

Note Fenix also has an about:support page now, so might we have the same problem there (triggering Android OS permissions)?

I just tried it and couldn't repro, but the GV buildid was 20200529095426 which sounds a couple of days old, so I dunno.

[Tracking Requested - why for this release]:
Although this is not amazing, it's somewhat expected to have to iron out things like this on nightly/beta, but we should not release with this prompt still present.

We probably want to consider uplift for the patch that's already here, or if that's not safe, disabling this functionality on beta (perhaps only on macOS or where there'd be scary permission prompts). We don't actually do anything scary with the audio data (it doesn't get stored or sent anywhere, or processed in any way besides to figure out roundtrip latency) so it's just the prompt which is scary.

Some older cameras like the Microsoft LifeCam HD-3000 series will turn on the camera's live hardware indicator light on microphone access, but those are becoming rare.

https://hg.mozilla.org/mozilla-central/rev/6911e019190e

Paul please request uplift when you get a chance.

Comment on attachment 9153798 [details]
Bug 1642712 - Only use the microphone when authorized on macOS when gathering roundtrip latency. r?chunmin

Beta/Release Uplift Approval Request

• User impact if declined: A user that has never allowed Firefox to use the mic on macOS > 10.14 will see a prompt that asks for microphone access when visiting about:support, which is confusing
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This is wrapping the call to the function we need for round-trip audio latency estimation in a conditional that checks that the permissions has been granted to Firefox. If the permission was never granted, then the page does nothing. If it was granted, then the number is fetched, but that's been in nightly for some time now.
• String changes made/needed:

Comment on attachment 9153798 [details]
Bug 1642712 - Only use the microphone when authorized on macOS when gathering roundtrip latency. r?chunmin

avoid permission prompt in about:support on mac, approved for 78.0b3

https://hg.mozilla.org/releases/mozilla-beta/rev/006eae4365a2

Tried on two different mac laptops (10.15) but did not manage to reproduce this in the first place so I can't verify that this is fixed. sea-wa can you confirm that this is no longer an issue using latest Nightly and the following build?

https://www.mozilla.org/en-US/firefox/all/#product-desktop-beta

I can still reproduce the issue on my working machine, running macOS 10.15.6 and Firefox 80.0 beta (20200818235255).

It might be best to file a new bug.

(In reply to Julien Cristau [:jcristau] from comment #16)

It might be best to file a new bug.

This. Andreas, can you file a new bug please? Otherwise it's just going to be confusing to track what is fixed in what release.

I don't see how that makes things easier, on the contrary. This issue has not been fixed in any release.

(In reply to Andreas Wagner [:TheOne] [use NI] from comment #18)

I don't see how that makes things easier, on the contrary. This issue has not been fixed in any release.

It's not fixed for you, I get that, but it seems fixed for me (I just downloaded a new devedition build in a new location with a clean profile and checked; I also checked my macOS "security and privacy" pane, which lists no Firefox builds at all under either camera or microphone).

In any case, we pretty much never reopen bugs unless the patch has been backed out or when it's clear that everyone who had the issue before is still seeing it. Reopening bugs after 2 months makes blame confusing ("the commit message points to this bug which was resolved at point N, but this code is in some build from before N?"), makes release tracking flags confusing, etc. etc.

Please file a new bug with detailed STR.

Oops, forgot the needinfo for comment #19.

Understood, thanks.