Stable to insiders smoke test: Can't restore remote repo

[bamurtaugh]

Testing #147702

• Open remote GH repo in VS Code Stable through GitHub Repositories extension
• Launch VS Code Insiders with same Stable user-data-dir
• Prompted to sign into GH to use GH Repositories extension
• Directed to new browser tab to sign in. Accept prompt from browser tab to sign in and reopen VS Code Insiders.
• New VS Code Insiders instance opens, without the same user-data-dir (i.e. dark theme instead of user-data-dir's light theme). It doesn't open the repo. The first Insiders instance is stuck in a loading state.

First Insiders instance (with error after some time, You have not yet finished authorizing this extension to use GitHub. Would you like to keep trying?):

Second Insiders instance:

---

I closed the second Insiders instance and selected Yes from prompt in first Insiders instance to keep trying.

I'm redirected to this browser page:

VS Code Insiders reloads and gets further as it shows the notebook top bar (i.e. Code, Markdown, and Run All buttons), but it now shows error: Error loading webview: Error: Could not register service workers: InvalidStateError: Failed to register a ServiceWorker: The document is in an invalid state..:

[bpasero]

My speculation is that the protocol handler from the browser opens VSCode insiders by default, and not the instance that is already running. In other words:

• you run code with --user-data-dir
• a browser opens for login
• the protocol handler opens code
• a normal code instance launches without --user-data-dir

So at this point you have 2 instances running, the normal one with default user data dir and the one you had started.

On macOS I actually also see this happening but only when Code is already running.

Moving to auth/remote owners, but maybe we just close this as designed and accept this as a limitation of how protocol handlers work. I do not think there is a way to handle protocol links any different, because we just register them with the OS.

The last error with regards to the service worker seems already reported at #148114

[bpasero]

Actually the relevant code for registering Code to Windows seems to be this:

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

Lines 54 to 58 in 4a130c4

	if (isWindows) {
	const windowsParameters = environmentMainService.isBuilt ? [] : [`"${environmentMainService.appRoot}"`];
	windowsParameters.push('--open-url', '--');
	app.setAsDefaultProtocolClient(productService.urlProtocol, process.execPath, windowsParameters);
	}

I am not suggesting to change this code, but we could probably detect the --user-data-dir argument and then register with different window parameters, but that might just ask for trouble.

@joaomoreno I think you added that a long time ago.

[TylerLeonhardt]

I added a bunch of fallback logic in GitHub Auth this milestone which is why you see the "you are signed in and can close this page" window. You use to just end up in a bad state. I agree with @bpasero that this should be closed as "as designed" because I feel like users shouldn't really be using --user-data-dir unless for troubleshooting.... but that's my 2 cents.

[joaomoreno]

I am not suggesting to change this code, but we could probably detect the --user-data-dir argument and then register with different window parameters, but that might just ask for trouble.

Oh wow yeah good observation. But I'm also too afraid to change it at this point.

[TylerLeonhardt]

I think we're in agreement not to do anything here for now.