[Problem/Bug]: CDP server connection - different applications visible through localhost and loopback

[marekpiotrowski-smartbear]

What happened?

Hello there, hope you guys are doing all right!

We're currently working on providing support for WebView2 applications in our software, and I think we encountered an issue. WebView2 applications expose a CDP server through port 9222 (we followed the tutorial here re editing registers https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/debug-visual-studio-code). There are kinda two problems though:

1. The CDP server sometimes starts on IPv6 and sometimes on IPv4 explicitly. Here's a small script I used for tests (could've been a GET in the browser I guess...):

import requests

host = 'http://127.0.0.1'
port = '9222'
path = 'json'
url = host + ':' + port + '/' + path

data = ''''''
print(f"Retrieving endpoints through {url}")
response = requests.get(url, data=data)

print('status code:' + str(response.status_code))
print(response.text)

now when changing the host to http://localhost, I'm getting different debugger endpoints:

(tc-assistant-venv) C:\Repositories>python test_wv2.py
Retrieving endpoints through http://localhost:9222/json
status code:200
[ {
   "description": "",
   "devtoolsFrontendUrl": "/devtools/inspector.html?ws=localhost:9222/devtools/page/90138856DA635ED2D27309116A6CE4D3",
   "id": "90138856DA635ED2D27309116A6CE4D3",
   "title": "Widgets",
   "type": "page",
   "url": "https://windows.msn.com/app.html?locale=en-US&region=PL&aver=524.16300.20.0&over=10.0.22621.3880.amd64fre.ni_release.220506-1250&fring=Retail&devicetype=10&oem=Dell%20Inc.&smode=false&machineId=%7B19652E3C-BCBE-4D6C-B359-C91E11545409%7D&clv=1.0&usri=-2&wver=126.0.2592.113&renderWidget=true&useDeployedBundles=true&fullrefreshint=0",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/90138856DA635ED2D27309116A6CE4D3"
} ]


(tc-assistant-venv) C:\Repositories>python test_wv2.py
Retrieving endpoints through http://127.0.0.1:9222/json
status code:200
[ {
   "description": "",
   "devtoolsFrontendUrl": "/devtools/inspector.html?ws=127.0.0.1:9222/devtools/page/FA1533B1D72AAE8D2D306A625DAC3751",
   "id": "FA1533B1D72AAE8D2D306A625DAC3751",
   "title": "Microsoft Edge WebView2",
   "type": "page",
   "url": "https://appassets.example/AppStartPage.html?sdkBuild=2646.0&runtimeVersion=126.0.2592.113&appPath=C:\\Repositories\\WebView2Samples\\SampleApps\\WebView2APISample\\Debug\\x64&runtimePath=C:\\Program%20Files%20(x86)\\Microsoft\\EdgeWebView\\Application\\126.0.2592.113",
   "webSocketDebuggerUrl": "ws://127.0.0.1:9222/devtools/page/FA1533B1D72AAE8D2D306A625DAC3751"
} ]

The first one, "Widgets", most probably comes with MS Outlook, whilst the other is one of your official samples (x64) which we're using for tests.

When checking what's going on on port 9222, this is what I'm seeing, which's also quite disturbing:

(tc-assistant-venv) C:\Repositories>netstat -ano | findstr 9222
  TCP    127.0.0.1:9222         0.0.0.0:0              LISTENING       13544
  TCP    [::1]:9222             [::]:0                 LISTENING       14004

2. The bigger problem IMO is that if both of those are occupied and we started another instance, it won't even appear on the list. I had a situation like that having started MS Outlook, VS (which also uses some WebView2 internally) and your Sample app. Your sample app never even shows up on the list then :(

The question here: shouldn't WebView2 Runtime/Manager/Whatever somehow figure out that the CDP server has already been started and somehow "attach" the new application there? Or else, how are we supposed to know which URL to query? I guess that if the PID would've been supplied together with the debugger URL, we could somehow do an exhaustive search over both addresses (given the start properly, as per point 2!), but it's not there. The experimental CDP API for getting the process info (https://chromedevtools.github.io/devtools-protocol/tot/SystemInfo/#method-getProcessInfo) does not seem to be working either.

The workaround for now would be to kill all processes occupying port 9222 (npx-kill port 9222 for example) and then immediately start the process we're interested in. What we're seeing through http://localhost:9222 is the what we expect. But as you may imagine, this is not ideal...

Importance

Blocking. My app's basic functions are not working due to this issue.

Runtime Channel

Stable release (WebView2 Runtime)

Runtime Version

126.0.2592.113

SDK Version

1.0.2646-prerelease

Framework

Win32

Operating System

Windows 11

OS Version

10.0.22621

Repro steps

1. Start some relatively new MS Outlook/Teams/VS (whatever that uses WebView2 internally somewhere).
2. Compile and link one of your official samples (https://github.com/MicrosoftEdge/WebView2Samples/tree/main/SampleApps/WebView2APISample), preferably for x64, can be Debug version, does not matter.
3. Start the Sample application.
4. Query http://127.0.0.1:9222/json in your favorite browser, then query http://localhost/json and notice that the JSON is different and different debugger URLs are reported.

Repros in Edge Browser

No, issue does not reproduce in the corresponding Edge version

Regression

Don't know

Last working version (if regression)

No response

AB#52885780

[LiangTheDev]

This seems to be due to forcing all WebView2 apps to create WebView2 with --remote-debugging-port=9222. We should only force the app that is being debugged to do so.

I assume that you have followed the instruction and created a registry value named * under HKEY_CURRENT_USER\Software\Policies\Microsoft\Edge\WebView2\AdditionalBrowserArguments with value data of --remote-debugging-port=9222. Try to use the exe file name instead of * as the name of the registry value. Like for the sample app, make the registry value name as WebView2APISample.exe. https://learn.microsoft.com/en-us/microsoft-edge/webview2/reference/win32/webview2-idl?view=webview2-1.0.2592.51#createcorewebview2environmentwithoptions has more details these registry values. You can also use https://github.com/david-risney/WebView2Utilities to set the additional browser arguments override for specific apps.

The documentation needs some update. I'll create an internal work item to track that.

[champnic]

✅ Successfully linked to Azure Boards work item(s):

• Bug 52885780

[champnic]

Docs updated to specify app exe:
https://learn.microsoft.com/en-us/microsoft-edge/webview2/how-to/debug-visual-studio-code#debug-running-processes

Thanks!

[marekpiotrowski-smartbear]

Wow hey guys, thank you so much for responding so promptly! Seems to be doing the trick, when I replaced the asterisk with WebView2APISample.exe it seems that the same debugger is available through localhost and loopback. Let's see if editing this particular register dynamically (programmatically) will work or there'll be a need for some further gymnastics re. refreshing that value.

Huge thank you for updating the documentation, love it. Just a suggestion: you could add a reference to the page which describes the environment variables associated with CDP debugger (that's the one you linked @LiangTheDev: https://learn.microsoft.com/en-us/microsoft-edge/webview2/reference/win32/webview2-idl?view=webview2-1.0.2592.51#createcorewebview2environmentwithoptions). Also, a question here, I've searched for a while but cannot find a proper example - if I wanted to set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS, how am I supposed to "encode" that for a specific application? Here's what's written down there:

To enable debugging of the targets identified by the JSON, you must set the WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS environment variable to send --remote-debugging-port={port_num}, where the following is true. (...)

So how would that look like when doing a set in CMD?
set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS="WebView2APISample.exe=--remote-debugging-port=9222"? I don't think this is even remotely a proper syntax 😄

Once again, thank you so much for help! Would appreciate an example with WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS env variable, but I guess you're super busy so whenever you find a moment!

Cheers,
Marek

[LiangTheDev]

Glad that it worked. For environment variable, it should be set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--remote-debugging-port=9222 (set WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS="--remote-debugging-port=9222" also works), but it would impact all apps seeing this environment variable. So, it is not recommended to use it. If you are able to launch the app using command line, you could simply launch it with --edge-webview-switches with the switches like WebView2APISample.exe --edge-webview-switches=--remote-debugging-port=9222.

[marekpiotrowski-smartbear]

Oh that: WebView2APISample.exe --edge-webview-switches=--remote-debugging-port=9222 looks like our guy! We actually run that from C++ and definitely have control over the command line itself - even better, we expose UI for extra command line arguments which means this can be delegated to end-users (with some proper docs on our end).

Huge thank you one more time. Have a great day!