Have same profile associated to any empty window

[jvillemure]

Type: Bug

Hi, I was an early user of the experimantal settings profile feature, and the functionality used to worked before 1.76, and also back when it was still an experimental feature.

Since I have distinct sets of user settings between my personal vscode and my workspace vscode, I defined a profile named 'cat' for my workplace and I use the default one for my personal use.

Problem since 1.76: when I open a workspace/a new window/reopen in container/and in some other cases of opening, the current Settings profile would sometimes unexpectedly change from the one I use at work 'cat' to the Default one. This didn't happen before.

I also, encountered issues with my profile extensions not being installed when I create a devcontainer. Similarly, I use wsl at work, and since this week, when i open a window in wsl I don't see any installed extension on the wsl remote when using my 'cat' profile settings, even though the ~/.vscode-server/extensions contains all extensions I have already installed.

The settingss profile seem to have been broken in many ways since 1.76.

VS Code version: Code 1.76.0 (92da948, 2023-03-01T10:22:44.506Z)
OS version: Windows_NT x64 10.0.19045
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz (16 x 2496)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	15.73GB (2.07GB free)
Process Argv	--crash-reporter-id c5a1a827-bcc3-4406-8db9-b4ae3a1d12c9
Screen Reader	no
VM	0%

Extensions (66)

Extension	Author (truncated)	Version
language-x86-64-assembly	13x	3.0.0
Bookmarks	ale	13.3.1
language-gas-x86	bas	0.0.2
cmake-format	che	0.6.11
doxdocgen	csc	1.4.0
unicodepalette	Dal	1.0.4
vscode-markdownlint	Dav	0.49.0
shebang-language-associator	dav	1.4.0
gitlens	eam	13.3.1
EditorConfig	Edi	0.16.4
file-icons	fil	1.0.29
shell-format	fox	7.2.5
codespaces	Git	1.13.10
remotehub	Git	0.52.0
vscode-pull-request-github	Git	0.59.2023030209
cpp-reference	Guy	0.2.3
vscode-drawio	hed	1.6.6
better-shellscript-syntax	jef	1.4.2
vscode-graphviz	joa	0.0.6
bash-ide-vscode	mad	1.34.0
vscode-catch2-test-adapter	mat	4.3.10
code-point	med	1.9.0
git-graph	mhu	1.30.0
file-downloader	min	1.0.12
vscode-boost-jam	mlo	0.0.2
azure-pipelines	ms-	1.208.0
vscode-docker	ms-	1.24.0
gather	ms-	2022.3.2
isort	ms-	2023.9.10591013
pylint	ms-	2023.5.10621012
python	ms-	2023.5.10621945
vscode-pylance	ms-	2023.3.11
jupyter	ms-	2023.3.1000641008
jupyter-keymap	ms-	1.1.0
jupyter-renderers	ms-	1.0.15
vscode-jupyter-cell-tags	ms-	0.1.6
vscode-jupyter-slideshow	ms-	0.1.5
remote-containers	ms-	0.283.0
remote-ssh	ms-	0.99.2023030315
remote-ssh-edit	ms-	0.84.0
remote-wsl	ms-	0.76.1
vscode-remote-extensionpack	ms-	0.24.0
azure-account	ms-	0.11.3
azure-repos	ms-	0.28.0
cmake-tools	ms-	1.14.15
cpptools	ms-	1.14.4
cpptools-extension-pack	ms-	1.3.0
hexeditor	ms-	1.9.11
makefile-tools	ms-	0.6.0
powershell	ms-	2023.2.1
remote-explorer	ms-	0.3.2023021509
remote-repositories	ms-	0.30.0
remote-server	ms-	1.1.2023022709
test-adapter-converter	ms-	0.1.6
vsliveshare	ms-	1.0.5832
vscode-commons	red	0.0.6
vscode-xml	red	0.25.2023022303
vscode-yaml	red	1.11.10112022
vscode-sort-json	ric	1.20.0
conanlight	Son	1.4.0
code-spell-checker	str	2.18.0
shellcheck	tim	0.29.4
intellicode-api-usage-examples	Vis	0.2.7
vscodeintellicode	Vis	1.2.30
vscode-icons	vsc	12.2.0
cmake-highlight	zch	0.0.1

(1 theme extensions excluded)

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vslsvsres303:30308271
pythonvspyl392:30443607
vserr242:30382549
pythontb:30283811
vsjup518:30340749
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
cmake_vspar411:30581797
vsaa593cf:30376535
pythonvs932:30410667
cppdebug:30492333
vsclangdf:30486550
c4g48928:30535728
dsvsc012:30540252
azure-dev_surveyonecf:30548226
pyindex848:30662994
nodejswelcome1:30587005
3biah626:30602489
pyind779:30671433
89544117:30613380
pythonsymbol12:30671437
2i9eh265:30646982
showlangstatbar:30672706
vsccsb:30677849
funwalk2cf:30676044

[sandy081]

Thanks a lot for using profiles feature.

I also, encountered issues with my profile extensions not being installed when I create a devcontainer. Similarly, I use wsl at work, and since this week, when i open a window in wsl I don't see any installed extension on the wsl remote when using my 'cat' profile settings, even though the ~/.vscode-server/extensions contains all extensions I have already installed.

I think this is tracked and answered here #176275

when I open a workspace/a new window/reopen in container/and in some other cases of opening, the current Settings profile would sometimes unexpectedly change from the one I use at work 'cat' to the Default one. This didn't happen before.

Can you please provide steps to reproduce this behaviour?

[jvillemure]

okay, I'll find some free time to explain steps.

But before, I might have a comment related to scoping settings profile per remote: I woud normally rely on the setting "dev.containers.defaultExtensions" to automatically install extensions in my new devcontainers, but this setting only applies in the default settings profile and there seems to be no way to make this setting apply when creating a new devcontainer. That's annoying, because now I need to explicitly copy paste the the list of extensions to any new devcontainer I create.

[jvillemure]

About the Settings Profile switching unexpectedly, here are some steps.

Before release 1.76, I would normally set my work profile 'work' at my workspace and then (almost) never touch it again (actually, recently I had to swap between my default and work profile to try experiments because I don't understand the new behavior). Formerly, anytime I would open a folder/workspace/remote and even an empty window, the current settings profile would always be exactly the same as the one of the last closed instance (and if I remember right, all window shared the current settings profile).

Today I experienced the following misbehavior:

1. when opening a new empty window(and no other window is open), the settings profile keeps being reset to the default profile. Steps to reproduce:
   • open an empty window
   • set profile to Default
   • close the window
   • open an empty window
   • change the profile to a non default (let's say 'work')
   • close the window
   • open an empty window
     Expected result: the last window should have the 'work' settings profile
     Actual result: the last window is in the Default settings profile

There are several other cases where this unexpected switching occurs, in particular when reopening a folder/workspace from a window with an active folder or connected to a remote. One case of unexpected profile switching that is problematic is when creating a new devcontainer: it is imperative that the current settings profile be kept as the settings in it are necessary for the container build to be successful. (I'll come back to give steps to repro for these ones, when I'll have some spare time).

[jvillemure]

I experienced another variant of this same issue today. Last week I when closing my last vscode window, it was using my non default work profile. This morning, I logged in then I opened a first empty vscode window.
Expected behavior: the vscode window uses the same profile that was used in the last closed vscode instance on my workplace machine.
Actual behavior: the vscode window was using my default profile

[sandy081]

But before, I might have a comment related to scoping settings profile per remote: I woud normally rely on the setting "dev.containers.defaultExtensions" to automatically install extensions in my new devcontainers, but this setting only applies in the default settings profile and there seems to be no way to make this setting apply when creating a new devcontainer. That's annoying, because now I need to explicitly copy paste the the list of extensions to any new devcontainer I create.

This is fixed already and will be available in next release.

About the Settings Profile switching unexpectedly

This is expected for empty windows. Every empty window is treated separately and independent just like a separate workspace. Hence you can assign different profiles for empty windows.

If you want all empty windows to have same profile, we can provide a configuration for that. But before that can you please let me know why you need this and how you would use this?

[sandy081]

I see this issue has been side tracked from comment onwards.

To replace default profile please follow #168867

[vscodenpa]

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

[sandy081]

You can now associate a profile for new window using the setting window.openFilesInNewWindow For more information please refer to this issue - #194105 (comment)

Therefore, I am closing this issue in favour of above setting. Please use this feature and provide your feedback.