Empty window opened on new window command

[psulek]

Issue Type: Bug

Having opened folder in 1st window and execute "New window command" (Ctrl+Shit+N) it opend empty new window without menus, statusbar empty sidedar collapsed.

Edit: Opening from windows explorer context menu on folder "Open with Code" will open vscode window succesfully without issue.

VS Code version: Code 1.58.1 (2aeda6b, 2021-07-13T06:58:28.115Z)
OS version: Windows_NT x64 10.0.18362
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-9700 CPU @ 3.00GHz (8 x 3000)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: enabled opengl: enabled_on rasterization: enabled skia_renderer: enabled_on video_decode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	undefined
Memory (System)	31.79GB (18.33GB free)
Process Argv	--crash-reporter-id fd5889aa-05ef-4447-88c4-3d2c42a38dc1
Screen Reader	no
VM	0%

Extensions (44)

Extension	Author (truncated)	Version
vscode-css-formatter	aes	1.0.1
vscode-nginx-conf	ahm	0.1.3
numbered-bookmarks	ale	8.1.0
open-html-in-browser	cod	0.1.21
vscode-eslint	dba	2.1.23
createuniqueid	don	0.0.3
githistory	don	0.6.17
xml	Dot	2.5.1
vscode-wasm	dts	1.3.1
tsl-problem-matcher	eam	0.4.0
vscode-npm-script	eg2	0.3.22
vscode-great-icons	emm	2.1.79
json-tools	eri	1.0.2
vscode-statusbar-debugger	fab	2.0.7
auto-rename-tag	for	0.1.7
gc-excelviewer	Gra	3.0.42
todo-tree	Gru	0.0.213
vscode-nginx-conf-hint	han	0.1.0
beautify	Hoo	1.5.0
minify	Hoo	0.4.3
githd	hui	2.2.4
output-colorizer	IBM	0.1.2
bridlensis	idl	1.2.2
nsis	idl	3.42.0
nsis-plugins	idl	1.3.0
nsl-assembler	idl	1.2.1
svg	joc	1.4.7
csharp	ms-	1.23.13
powershell	ms-	2021.6.2
debugger-for-chrome	msj	4.12.12
gulptasks	nic	1.3.1
vetur	oct	0.34.1
run-as	ply	1.8.27
vscode-thunder-client	ran	1.7.1
nginx-formatter	ray	0.0.13
typescript-hero	rbb	3.0.0
vscode-sort-json	ric	1.20.0
ActiveFileInStatusBar	Ros	1.0.3
vscode-nginx	sha	0.6.0
move-ts	str	1.12.0
html-preview-vscode	tht	0.2.5
vscode-nginx	wil	0.7.2
webpack-progress	wk-	0.0.8
vscode-surround	yat	1.1.2

(5 theme extensions excluded)

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383cf:30185419
pythonvspyt700cf:30270857
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551:30311712
vspre833:30321513
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
vscoreces:30322571
pythondataviewer:30285071
vscus158:30321503
pythonvsuse255:30335481
vscod805cf:30301675
pythonvspyt200:30331937
vscextlang:30333561
binariesv615:30325510
bridge0708:30335490

[deepak1556]

Can you provide the output of code --verbose when you perform the above steps. Also do you have vscode installed in a symlinked directory ?

[psulek]

@deepak1556 i can't reproduce it again today. Maybe some extension is updated with fixed or something.

[deepak1556]

Closing for now, can reopen if the issue reappears.

[psulek]

I can reproduce this bug. Open code --verbose, open folder, then press Ctrl+Shift+C to execute Open New External Terminal (workbench.action.terminal.openNativeConsole) and new CMD (windows) is showed. Now return to one opened VSCode and hit Ctrl+Shift+N to open new window and error occurs (new empty vscode window).

vscode-log-partial.txt - contains logs right after new empty vscode window opened
vscode-log-full.txt - contains logs after exit of all vscode windows.

Hopes logs helps @deepak1556

[deepak1556]

Thanks for the repro! I can confirm the issue.

[deepak1556]

Okay the issue turned out to be quite simple but has bad side effects. When launching the external terminal we try to sanitize the process environment

vscode/src/vs/platform/externalTerminal/node/externalTerminalService.ts

Lines 314 to 318 in 4e5d793

	function getSanitizedEnvironment(process: NodeJS.Process) {
	const env = process.env;
	sanitizeProcessEnvironment(env);
	return env;
	}

and this removes vscode specific keys

vscode/src/vs/base/common/processes.ts

Lines 109 to 114 in 4e5d793

	const keysToRemove = [
	/^ELECTRON_.+$/,
	/^VSCODE_.+$/,
	/^SNAP(|_.*)$/,
	/^GDK_PIXBUF_.+$/,
	];

Since we are experimenting with the protocol used for workbench resource loading, we have put it behind an environment variable

vscode/src/main.js

Lines 248 to 250 in 4e5d793

	if (cliArgs.__sandbox || browserCodeLoadingStrategy) {
	process.env['VSCODE_BROWSER_CODE_LOADING'] = browserCodeLoadingStrategy || 'bypassHeatCheck';
	}

which will get respected in

vscode/src/bootstrap-window.js

Line 27 in 4e5d793

const useCustomProtocol = safeProcess.sandboxed || typeof safeProcess.env['VSCODE_BROWSER_CODE_LOADING'] === 'string';

to instruct our custom loader on how to resolve resource paths.

The sanitization of process environment for the terminal launch happens in main process and hence successive new window loads after launching external terminal fallback to file scheme because the env variable is no longer available. I will push a fix to preserve VSCODE_BROWSER_CODE_LOADING temporarily.

But @Tyriar this seems like a bigger issue if we are sanitizing env variables in the main process, since main process serves as source of truth, successive child process launched from the main process won't get the right variables.

/cc @bpasero

[Tyriar]

@deepak1556 it's a mistake that it's applying to process.env. This line should be { ...process.env }:

xtermjs/xterm.js#1134

[deepak1556]

\closedWith 34419f8

[psulek]

@deepak1556 is there any chance for fix build sooner then next month proper release? I cant work across this issue in work day :-(

[deepak1556]

You can use the insiders version https://code.visualstudio.com/insiders which is a nightly release.

[psulek]

You can use the insiders version https://code.visualstudio.com/insiders which is a nightly release.

I can (and will) but this bug should have high priority for vscode and maybe release early fix, because of the nature of bug (anyone can reproduce it, execute external terminal and then File -> New Window). Seems to be a big issue for vscode and its users ;-|

[deepak1556]

VSCode has a 4-week iteration cycle before a newer stable version is released. If there are critical bugs identified with relatively safe fixes in the first two weeks (this is a rough estimate depends on the candidate bugs that come in) after a stable release then we make a recovery patch releases. Otherwise the bug fixes just bake in the insiders for the rest of iteration before the next stable release.

In this case the bug was confirmed and fixed towards the end of current iteration, it is better for the fix to iterate in the insiders as the 1.59 release is gonna happen next week. Also the benefit of iterating with insiders helps us catch regressions that may arise from a fix before we are confident in shipping it to stable.