User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.4577.63 Safari/537.36

Steps to reproduce:

With the following preferences set:

'media.navigator.streams.fake': true
'permissions.default.microphone': 2  # blocked

and calling to navigator.mediaDevices.getUserMedia as such:

navigator.mediaDevices.getUserMedia({ audio: true })
  .then(=> { console.log('success') })
  .catch(=> { console.log('failure') })

Actual results:

With Firefox <= v91 the call to getUserMedia will log failure

With Firefox v92 it will log success without any request to the user to "allow".

I have tested with the same results on Ubuntu 18.04 and MacOS 11

Expected results:

As with Firefox <= v91, calling to getUserMedia should end up in the promise catch handler, thus in the example log failure.

I understand that the above two configuration options are somewhat at odds with each other, and it may be deemed to be a precedence order change. However this does feel like a regression, in that blocking microphone permissions should result in a failure even if the navigator streams are set to return "fake" streams.

I can confirm the same issue still applies in the Firefox Nightly build (v94.0a1 2021-09-10).

The Bugbug bot thinks this bug should belong to the 'Core::WebRTC: Audio/Video' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Karl, mozregression points to Bug 1720643. Does the behavior above match your expectations?

Thank you, Andrew for identifying the particular prefs involved, and Michael the regression trigger.

This was not an intended side-effect of the removal of one of two permissions checks.
However, before that change, the interaction of the preferences was not consistent: nsIPermissionManager::PROMPT_ACTION in "permissions.default.microphone" had no effect fake streams.

When the nsIPermissionManager code was introduced, fake streams were explicitly excluded unless "media.navigator.permission.fake" was set.
This was still the situation when "media.navigator.streams.fake" was introduced for tests.
I.e. the design was that "media.navigator.streams.fake" should usually cause permissions to be ignored.

Having DENY_ACTION permissions apply by default to fake streams seems to have been an accident.

The recent changes for bug 1720643 have restored the original behavior.

Permissions still take effect when "media.navigator.permission.fake" is set with "media.navigator.streams.fake". That may be a reasonable compromise, allowing permissions to have effect if desired, but defaulting to allowing fake streams without permission because they don't contain sensitive data.

Set release status flags based on info from the regressing bug 1720643

(In reply to Ryan VanderMeulen [:RyanVM] from comment #6)

(In reply to Karl Tomlinson (:karlt) from comment #4)

The recent changes for bug 1730163 have restored the original behavior.

That's this bug. Did you mean a different one here?

Thanks. Updated comment with bug 1720643.

(In reply to Etienne Bruines from comment #8)

Permissions still take effect when "media.navigator.permission.fake" is set with "media.navigator.streams.fake". That may be a reasonable compromise, allowing permissions to have effect if desired, but defaulting to allowing fake streams without permission because they don't contain sensitive data.

Somehow this "workaround" does not quite work when trying to allow fake streams.

Having DENY_ACTION permissions apply by default to fake streams seems to have been an accident.

The recent changes for bug 1720643 have restored the original behavior.

This is in line what I'm seeing now (Tested Firefox 92 and 94 nightly as of 2021-09-08, but not an issue in Firefox 91) - DOMException: The request is not allowed by the user agent or the platform in the current context regardless of the permissions-preferences.

Disregard this - seems like permissions are additionally controlled through the iframe-allow attribute, which was blocking the fake streams.

(I have no way of editing/removing my comment above)

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.