Windows: protocol handler opens a new window and not existing window

[willwad]

Issue Type: Bug

With this release, invocations of vscode-insiders:// links always result in a new instance of VS Code opening, and vscode.window.registerUriHandler registrations in the new instance never getting called.

I also see an error of:
Warning: 'open-url --' is not in the list of known options, but still passed to Electron/Chromium.

when doing system invocations of vscode-insiders://

This breaks the extension I own as it uses the URI hanlder to notify the extension from cmdlet actions in the terminal.

VS Code version: Code - Insiders 1.65.0-insider (d09aeab, 2022-02-09T05:16:17.063Z)
OS version: Windows_NT x64 10.0.22000
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz (12 x 3696)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.78GB (8.42GB free)
Process Argv	--crash-reporter-id eca4b774-c277-477f-863a-1ad060bb6a90
Screen Reader	no
VM	0%

Extensions (16)

Extension	Author (truncated)	Version
vscode-research	alb	201021.0.1
npm-intellisense	chr	1.4.0
vscode-markdownlint	Dav	0.46.0
vscode-eslint	dba	2.2.2
vscode-npm-script	eg2	0.3.24
vscode-drawio	hed	1.6.4
tdpcode	Mic	1.10.9
remote-ssh	ms-	0.70.0
remote-ssh-edit	ms-	0.70.0
remote-wsl	ms-	0.64.2
vscode-remote-extensionpack	ms-	0.21.0
cpptools	ms-	1.8.4
js-debug-companion	ms-	1.0.15
powershell-preview	ms-	2022.2.0
debugger-for-chrome	msj	4.13.0
code-spell-checker	str	2.1.6

A/B Experiments

vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyl392:30422396
pythontb:30258533
pythonvspyt551:30291412
pythonptprofiler:30281269
vsdfh931:30280409
vshan820:30294714
pythondataviewer:30285072
vscod805:30301674
pythonvspyt200:30323110
bridge0708:30335490
bridge0723:30353136
vsaa593cf:30376535
pythonvs932:30404738
wslgetstarted:30421357
vs360cf:30404996
vsclayoutctrc:30405799
pythonvsnew555:30426298
vscscmwlcmt:30428973
azactmsalcf:30432849
vscgsvid2:30433758

[yume-chan]

Related to #142666

[bpasero]

I can only reproduce since we use Electron 16, so I suspect it is related. And it only reproduces on Windows for me.

I am not so familiar with how we setup the protocol handler, code seems to be here:

vscode/src/vs/platform/url/electron-main/electronUrlListener.ts

Line 57 in 4a130c4

app.setAsDefaultProtocolClient(productService.urlProtocol, process.execPath, windowsParameters);

Maybe we no longer pass the arguments properly to the instance? Could this be related to the request single instance lock changes from @rzhao271 ?

[deepak1556]

request single instance lock exercises different code path than the protocol handler, so that change definitely shouldn't have an impact here.

Warning: 'open-url --' is not in the list of known options, but still passed to Electron/Chromium.

Considering this error, looks like the arg is incorrectly parsed. Not sure if its the runtime that is returning the bad argument, will check.

[bpasero]

I would expect this place to be the location where we handle the URI:

vscode/src/vs/code/electron-main/app.ts

Lines 819 to 833 in 01df559

	// Check for URIs to open in window
	const windowOpenableFromProtocolLink = app.getWindowOpenableFromProtocolLink(uri);
	if (windowOpenableFromProtocolLink) {
	const [window] = windowsMainService.open({
	context: OpenContext.API,
	cli: { ...environmentService.args },
	urisToOpen: [windowOpenableFromProtocolLink],
	gotoLineMode: true
	// remoteAuthority: will be determined based on windowOpenableFromProtocolLink
	});
	window.focus(); // this should help ensuring that the right window gets focus when multiple are opened
	return true;
	}

I added some logging at that place.

[bpasero]

Probably same as electron/electron#32463 which was reported against Electron.

[TylerLeonhardt]

This issue affects GitHub and Microsoft authentication flows, unfortunately so users will not be able to sign in at all until this is sorted. Just wanted to leave this context here as I will point others to this issue.

[IllusionMH]

Is MS Authenticator affected? I think it's "self hosted" server, so no app schema handlers should be triggered.

[TylerLeonhardt]

True, @IllusionMH. Using the protocol handler is only done in Microsoft Auth if spinning up that server you mention doesn't work which should be relatively rare... so in auth world this mostly affects GitHub auth. Unfortunately, GitHub auth is used more than Microsoft auth.

[IllusionMH]

Oh, nice to know. I stand corrected.

[deepak1556]

Will be fixed in today's insider

Refs https://domoreexp.visualstudio.com/Teamspace/_git/electron-build/pullrequest/479313

[TylerLeonhardt]

I verified that this isn't happening anymore, however, since it was related to the electron update and we've deferred that to March, I will move this out to March for true verification.