1642712 - about:support Asks for Microphone Access

Status: RESOLVED FIXED

(Core :: WebRTC: Audio/Video, defect, P1)

Description

[sea-wa]

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

Comment 1

[:Gijs (he/him)]

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?

Comment 2

[Paul Adenot (:padenot)]

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.

Comment 3

[Paul Adenot (:padenot)]

(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.

Comment 4

[Paul Adenot (:padenot)]

Attachment: Bug 1642712 - Only use the microphone when authorized on macOS when gathering roundtrip latency. r?chunmin

Comment 5

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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.

Comment 6

[:Gijs (he/him)]

[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.

Comment 7

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

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.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6911e019190e
Only use the microphone when authorized on macOS when gathering roundtrip latency. r=chunmin

Comment 9

[Dorel Luca [:dluca]]

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

Comment 10

[Julien Cristau [:jcristau] (back April 22)]

Paul please request uplift when you get a chance.

Comment 11

[Paul Adenot (:padenot)]

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 12

[Julien Cristau [:jcristau] (back April 22)]

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

Comment 13

[Ryan VanderMeulen [:RyanVM]]

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

Comment 14

[Bogdan Maris, Desktop QA]

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

Comment 15

[Andreas Wagner [:TheOne] [use NI]]

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

Comment 16

[Julien Cristau [:jcristau] (back April 22)]

It might be best to file a new bug.

Comment 17

[:Gijs (he/him)]

(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.

Comment 18

[Andreas Wagner [:TheOne] [use NI]]

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

Comment 19

[:Gijs (he/him)]

(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.

Comment 20

[:Gijs (he/him)]

Oops, forgot the needinfo for comment #19.

Comment 21

[Andreas Wagner [:TheOne] [use NI]]

Understood, thanks.