Edge Beta v86 broke policies for WebView2

[alexbond]

I see that after the update of Edge Beta to v86, the policies set in registry no longer work for Webview2-based browsers. E.g. I can freely download files on the browser despite DownloadRestrictions set to 3 (block all). 

Yet, there is no such problem with v85 (Stable channel), or when using standalone Edge Beta v86, policies are respected.

Is this a bug?

[#2]

@alexbond , this is a change introduced in recent release, see Release Notes for Microsoft Edge WebView2 for Win32, WPF, and WinForms - Microsoft Edge Development .... 

WebView does not respect Edge browser policies. Edge and apps are separate management scenarios and we don't want browser policies to affect apps (e.g. admin blocks JavaScript in Edge then realizes in horror that a bunch of apps are broken).

[#3 · Accepted solution]

@alexbond 

Like @LingAmy mentioned, this is by design. We believe that apps and browsers are separate scenarios, and admin usually doesn't know what is WebView2 or what apps use WebView2 (it's an implementation details to app). As Ling said, we want to prevent cases such as admin turning off JavaScript in Edge and then realizing in horror that a seemingly random set of apps on the device are broken because they use WebView2 and JavaScript underneath. 

Specifically to your comment about "Webview2-based browsers", these apps that are built on top of the browser. We recommend developers owning these apps to expose their own policies to control WebView2 download behavior, or admins can block those apps from installing if they are malicious.

[#4]

Thank you @liminzhu and @LingAmy 

with that, can you point to the WebView2 API that allows to block downloads on the WebView2-based browser, so I can implement my own policy on that?

[#5]

@alexbond download is one of the scenarios we're looking at actually. I'd encourage following https://github.com/MicrosoftEdge/WebViewFeedback/issues/419. 

There isn't a WebView2 API per se today that blocks download, but before we expose one, there is a workaround. You can use CallDevToolsProtocolMethod (https://docs.microsoft.com/en-us/microsoft-edge/webview2/reference/win32/0-9-622/icorewebview2#calld...) to call Chrome DevTool Protocol APIs (https://chromedevtools.github.io/devtools-protocol/) from WebView2, and Browser.setDownloadBehavior (https://chromedevtools.github.io/devtools-protocol/tot/Browser/#method-setDownloadBehavior) lets you block download.

[#6]

Thank you @liminzhu ,

that's very helpful. Can you also help me understand of the ways I can be informed about upcoming/planned disrupting changes like this with Webview2? This is impacting our company business and I'd want to avoid it when possible. Is there anything besides https://docs.microsoft.com/en-us/microsoft-edge/webview2/releasenotes I can look at?

Also, note that the above release notes state that browser policies disconnected in WebView v0.9.622.

Yet it's clear that this change is unrelated to WebView2 version (e.g. policy disconnect still happens with v0.9.430), and is rather tied to Edge v86 release with any compatible WebView2. You might want to correct the page to avoid confusion there. 

[#7]

@alexbond besides release notes, we recently made https://github.com/MicrosoftEdge/WebView2Announcements where you can subscribe and get notifications on announcements, API proposals, etc. We are making changes like this during preview so that we don't have to make them post GA.

> Yet it's clear that this change is unrelated to WebView2 version (e.g. policy disconnect still happens with v0.9.430), and is rather tied to Edge v86 release with any compatible WebView2. You might want to correct the page to avoid confusion there. 

You're right, the changes happen in Edge/WVRT. When we give out SDK release notes, it contains changes in both Edge and SDK. We can make that clear.