Option for overriding DeveloperToolsAvailability flag to allow access to the developer tools APIs

[MichaelKetting]

The Developer Tools can be disabled via the DeveloperToolsAvailability flag (see https://docs.microsoft.com/en-us/deployedge/microsoft-edge-policies#developertoolsavailability). As a developer I would like to still be able to use the developer tools apis that can be called via WebView2.CoreWebView2.CallDevToolsProtocolMethodAsync.

I looked around the available APIs but nothing seemed to work in getting the developer tools to work in the hosted scenario once they had been disabled by policy.

This would be needed for instance to access the cookie story #4 (comment), unless and until an offical API is provided. In general, there may a lot of stuff you could do with the developer tools apis while still hiding the developer tools from the user. However, in corporate environments, it is quite likely that the developr tools are disabled via policy to prevent the user from doing things they're not supposed to, causing help-desk overhead or security concerns. When hosting a browser control, this responsibility should fall to the developer relying on those features, not the admin.

AB#27617474

[pagoe-msft]

@MichaelKetting ,

This is great feedback! Are the developer tools disabled in your development environment? Or are they disabled in the environment in which you expect your WebView2 application to be deployed?

[killerbobjr]

I originally developed a method of method of accessing the "Cookies" file directly through sqlite (it was my first attempt at cookie management before figuring out the developer tools method). Unfortunately, it suffers from the drawback of cookies not being updated until the current page is unloaded, i.e. anything you read is not current and anything you write gets overwritten upon page unload.

To read current cookies, you would have had to load the page you want cookies for, load another page to get the Chrome engine to flush the cookies to file (using "about:blank" won't work -- it has to be a domain), then reload the page (or use "GoBack").

For write, you would have had to wait for a page unload (ICoreWebView2NavigationStartingEventHandler trigger for a new page), then pause within ICoreWebView2ContentLoadingEventHandler, make sure the "Cookie" file timestamp updated, write your cookie, then allow ICoreWebView2ContentLoadingEventHandler to continue.

It was a horrible kludge that I hope never sees the light of day.

If the Edge developer team doesn't either allow bypassing of this particular policy for hosted Edge or doesn't provide an Edge cookie API, I may have to release it. <shudder>

[MichaelKetting]

@pagoe-msft Thank you for the quick response! The second one would be the case, the customer disabling developer tools for support or security reasons. Given how far-reaching this setting is (i.e. affects all instances of Edge in the user session), it is not feasable to require customers to have developer tools enabled on their end-user systems to support our product.

[champnic]

@killerbobjr @MichaelKetting A Cookie API is on the way :) However we should still fix this - it's in our backlog.

[MichaelKetting]

@champnic This is great news! Thanks for the update.

[killerbobjr]

There is a Chrome switch, '--force-devtools-available', that apparently forces developer tool availability regardless of any policies, at least according to this list.

Set the switch when creating the initial environment:

auto options = Microsoft::WRL::Make<CoreWebView2EnvironmentOptions>();

options->put_AdditionalBrowserArguments(L"--force-devtools-available");

HRESULT hr = CreateCoreWebView2EnvironmentWithOptions(
	subFolder, 
	nullptr, 
	options.Get(), 
	Callback<ICoreWebView2CreateCoreWebView2EnvironmentCompletedHandler>(this, &AppWindow::OnCreateEnvironmentCompleted).Get());

If true, this would mean the cookie management issue in #4 has a complete solution right now, without needing to wait for any upcoming APIs. It also is a fix for this posted issue.

[MichaelKetting]

@killerbobjr yeah, we tried this back when when we evaluated your suggestion but didn't get anywhere with the switch. According to https://chromium-review.googlesource.com/c/chromium/src/+/1142104/ the switch was removed again some time after its introduction. It was only intended for ChromeOS.

[killerbobjr]

Darn! Well, if the Edge team could re-enable the switch via the 'put_AdditionalBrowserArguments' method while disallowing it from the Edge app command line, that would solve this issue. I wouldn't presume to know how they've structured Edge internally though, so that method may be not be viable.

[lingamy]

@MichaelKetting, thanks for your feedback! we have recently made a change such that Edge group policy won't impact WebView2 so this should no longer be an issue. If you don't want to show DevTools for your app, you can use WebView2 API AreDevToolsEnabled. This will remove the UI entry point for devtools from the app, and you can still call CDP programmatically.

[MichaelKetting]

@lingamy Thank you! Looking forward to getting this via the NuGet package. From the release notes, it's not in v0.9.579, correct?