Permission dialog box incorrectly displayed (or failure to trigger PermissionRequested event)

Contrary to what the documentation says, WebView-for-WPF displays the following dialog box (see following photo) asking the user for permission to access the microphone. AFAIK that's a bug because WebView should instead trigger the PermissionRequested event. The WebView documentation explicitly states that the microphone is included in the PermissionRequested event:

"Use PermissionRequested event to enable web features that require special capabilities. These currently include geolocation, IndexedDB storage, and user audio and video (for example, from a microphone or webcam)." -- https://docs.microsoft.com/en-us/uwp/api/windows.ui.xaml.controls.webview

Even if an app doesn't subscribe to PermissionRequested, the permission dialog box shouldn't have appeared, because the documentation states:

"If you don't handle the PermissionRequested event, the WebView denies permission by default."

Users view the dialog box as a problem or a malfunction

Although it might seem like the permission dialog box is harmless and easily understood, it actually causes a real problem in our environment. Although the dialog box seems simple to you and I, nevertheless it causes too many users to call or email tech support. Users don't know whether to click the "Yes" or "No" button, or they don't understand why the dialog box is appearing at all, or they believe that the existence of the dialog box indicates that the software is malfunctioning.

This doesn't mean they're stupid. It's not only the end-users who don't understand the dialog box -- I also cannot explain why it appears, despite my technical experience and knowledge. I simply viewed the same website as the end-users (a website unrelated to audio recording) and the microphone permission dialog box appeared but why?

WebView shouldn't cause permanent changes to OS settings

Another reason why the permission dialog box causes real problems: When users click either the "Yes" or "No" button, it permanently changes an OS setting in the computer, meaning that different computers end up with different settings:

On some computers, users click "Yes",
and on some other computers, users click "No",
and on some other computers, users don't click anything and instead walk away and either abandon the computer or contact tech support for assistance.

It's very bad when WebView causes different computers to have different settings in the OS, permanently, because this leads to significant debugging/diagnostic and tech support difficulties. How can we successfully troubleshoot/maintain a thousand different computers when they all end up with different combinations of settings in the OS?

Someone tests something on one computer and then someone else tries to reproduce the same problem on other computer but the computers behave differently because WebView permanently changed the settings in each computer to differing values. This is a real problem in terms of delivering reliable tech support and maintenance for a large quantity of computers. Major headaches and troubleshooting delays occur when each computer behaves differently because of different OS settings.

The fact that a XAML Control (in this case WebView) causes permanent changes to OS settings is actually strange, unexpected, problematic behavior. Thus the permission dialog box isn't as harmless and simple as it may seem at first glance.

Expected behavior

WebView's behavior should match the description of the PermissionRequested event in the documentation.

Please make it so that WebView doesn't display ANY dialog boxes at all. Instead please notify the app via events and let the app decide what to do in response to the event. The app can decide for itself whether to display its own dialog box or message in response to events triggered by WebView.

When WebView displays any dialog boxes, it's actually a substantial problem in our environment. We would very much appreciate the ability to suppress or redirect ALL dialog boxes via events such as PermissionRequested and/or settings in WebView etc.

Mandatory permission dialog box to GRANT permission

I realize that for security reasons in UWP/sandboxed apps, when an app invokes Windows.UI.Xaml.Controls.WebViewPermissionRequest.Allow(), then the OS may need to display a mandatory permission dialog box, but even in this case, I still think that WebView should NOT cause any dialog box to be displayed, rather WebView should make it the responsibility of the app to gain the necessary permission from the OS.

Thus apps would be required to perform 2 steps to grant permission:

Gain the necessary permission from the OS via the app manifest or by invoking a UWP method that displays a permission dialog box.
Invoke Windows.UI.Xaml.Controls.WebViewPermissionRequest.Allow(). This should only take effect if the other/aforementioned step is also performed (either before or after invoking Allow).

Environment

First I tested with WebView-for-WPF version 6.0.0-preview7.1, and then I wanted to test it again with 6.0.0-preview9.1, but when you click either the "Yes" or "No" button, an OS setting is permanently changed and the dialog box doesn't appear again. How can this setting be reset to test WebView again? But actually, WebView should never change any OS settings permanently.

Windows 10 version 1903 build 18362.418.

Release notes?

Are there any release notes or a change list for WebView-for-WPF? What's the difference between version 6.0.0-preview9.1 and 6.0.0-preview7.1 ? A brief bullet-point change list would be quite helpful because then we could immediately test the specific areas of WebView-WPF that were changed, each time a new version of the nuget package is released. WebView is very important in our environment so we'll make it a priority to test new versions.

CommunityToolkit / Microsoft.Toolkit.Win32