Secondary sidebar opens empty, requiring extra click

[digitarald]

Type: Bug

STR:

• Put Chat into the secondar sidebar
• Reload the window
• White it still loads, open the sidebar

Sidebar is stuck in blank state. This happens often for me, and always takes me a minute as I hope it still loads.

Clicking the chat icon or closing/opening it does load the chat panel.

VS Code version: Code - Insiders 1.80.0-insider (f3aa9a2, 2023-06-14T09:04:32.379Z)
OS version: Darwin x64 22.5.0
Modes:

System Info

Item	Value
CPUs	Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz (16 x 2400)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled metal: disabled_off multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: enabled
Load (avg)	6, 5, 4
Memory (System)	64.00GB (6.30GB free)
Process Argv	--enable-proposed-api digitarald.chat-ai-plugins --log trace --crash-reporter-id 4cf0a6f0-aaf8-4da3-9b2b-81f6c639c12b
Screen Reader	no
VM	0%

Extensions (74)

Extension	Author (truncated)	Version
html-snippets	abu	0.2.1
Bookmarks	ale	13.3.1
tsl-problem-matcher	amo	0.6.2
docs-view	bie	0.0.11
emojisense	bie	0.10.0
github-markdown-preview	bie	0.3.0
markdown-checkbox	bie	0.4.0
markdown-emoji	bie	0.3.0
markdown-footnotes	bie	0.1.1
markdown-mermaid	bie	1.18.1
markdown-preview-github-styles	bie	2.0.2
markdown-yaml-preamble	bie	0.1.0
esbuild-problem-matchers	con	0.0.2
vscode-eslint	dba	2.4.0
chat-ai-plugins	dig	0.0.1
githistory	don	0.6.20
kusto	don	0.4.4
EditorConfig	Edi	0.16.4
prettier-vscode	esb	9.13.0
auto-close-tag	for	0.5.14
auto-rename-tag	for	0.1.10
codespaces	Git	1.14.8
copilot-chat	Git	0.0.1
copilot-labs	Git	0.14.884
copilot-nightly	Git	1.89.161
remotehub	Git	0.57.2023051001
vscode-github-actions	git	0.25.7
vscode-pull-request-github	Git	0.67.2023061409
github-security-alerts	los	0.0.4
cortex-debug	mar	1.12.0
debug-tracker-vscode	mcu	0.0.15
memory-view	mcu	0.0.21
peripheral-viewer	mcu	1.4.6
rtos-views	mcu	0.0.7
theme-monokai-pro-vscode	mon	1.2.1
vscode-azurefunctions	ms-	1.11.0
vscode-azureresourcegroups	ms-	0.7.5
vscode-docker	ms-	1.25.1
dotnet-interactive-vscode	ms-	1.0.4313020
vscode-dotnet-runtime	ms-	1.6.0
isort	ms-	2023.9.11571010
python	ms-	2023.11.11651007
vscode-pylance	ms-	2023.6.11
jupyter	ms-	2023.6.1001671100
jupyter-keymap	ms-	1.1.0
jupyter-renderers	ms-	1.0.15
vscode-ai	ms-	0.32.2
remote-containers	ms-	0.296.0
remote-ssh	ms-	0.103.2023061415
remote-ssh-edit	ms-	0.86.0
remote-wsl	ms-	0.79.5
anycode	ms-	0.0.72
azure-account	ms-	0.11.5
azure-repos	ms-	0.35.2023061201
cpptools	ms-	1.15.4
live-server	ms-	0.4.8
remote-repositories	ms-	0.36.0
remote-server	ms-	1.3.2023061409
vscode-github-issue-notebooks	ms-	0.0.129
vscode-markdown-notebook	ms-	0.0.26
vscode-selfhost-test-provider	ms-	0.3.15
vscode-typescript-next	ms-	5.2.20230614
vsliveshare	ms-	1.0.5873
particle-vscode-pack	par	1.16.1
particle-vscode-snippets	par	1.16.1
vscode-xml	red	0.25.0
vscode-yaml	red	1.13.0
kuskus-kusto-syntax-highlighting	ros	1.1.21
cody-ai	sou	0.3.20230615
sourcegraph	sou	2.2.16
rest-book	tan	6.2.1
fugio	Tyl	0.0.2
vscode-mdx	uni	1.3.0
markdown-all-in-one	yzh	3.5.1

(2 theme extensions excluded)

[jrieken]

Marking this as important because it gives users the expression something is severely broken

[jrieken]

I gave this a stab but I'm throwing the towel, I don't really understand what's happening. When debugging I see that openPaneComposite is called with the container id of chat. This happens before the extension point handler for chat is executed and therefore nothing is restored. This again because the ChatContributionService is quite lazy and handles its extension point later.

Question: the panelPart seems to be missing that the pane/view/viewlet is eventually registered

I now attempted to fix this by registering chat views/viewlets a bit more eagerly, esp before openPaneComposite is called. I can see how register now happens before but for whatever reason the chat-viewlet isn't revealed but another viewlet of the same view 🤷

I am happy to continue the investigation and can make a PR but I am lost and would need someone pointing in the right direction.

[sbatten]

@jrieken thanks for taking a look at this, but I think the root cause of this issue (as well as another issue regarding views getting reset) is that the Chat extension contribution point breaks the contract we have with the extension service. The chat view container and view are created by core but controlled by the interactive session extension point. In the view descriptor service, we rely on the extension service to tell us when all extensions have been processed (and all their contribution points have been processed). However, the chat contribution extension point is not registered until the chat contribution service is instantiated and thus happens AFTER the extension service tells us all extension contribution points have been processed. The true fix IMO is that ChatContributionService gets converted to a workbench contribution (much like views and view container contributions).

Additionally, this issue has been around since the chat view container got created. I would like to tackle this next iteration instead of trying to fix it in endgame.

[jrieken]

The true fix IMO is that ChatContributionService gets converted to a workbench contribution (much like views and view container contributions).

That's exactly what I have tried, I made sure that chat views are contributed after waiting for installed extensions here but then the wrong view would get focus-restored

I would like to tackle this next iteration instead of trying to fix it in endgame.

That's fine for me, I was just curious so I started to investigate

[sbatten]

That's exactly what I have tried, I made sure that chat views are contributed after waiting for installed extensions here but then the wrong view would get focus-restored

If I understand correctly, I mean the opposite. The chat views are essentially extension contributed views which need to be processed before that promise returns (that's the contract we have with the view descriptor service). I hackily ensured this by making the extension service depend on the chat contribution service and made it eager. This produced the desired result in my testing.

[sbatten]

fixed by #192827

[jrieken]

This only get's a half verified, see #194280