treeview started as closed need another refresh (or re-opening) to show content

[boltex]

Issue Type: Bug

I'm developping an extension, and i've noticed a problem that i can also reproduce with the gitlens default extension in vscode. (therefore prompting me to think it's an issue with vscode and not my extension)

Make sure the 'commits' section of gitlens is closed when
closing vscode.

Restart vscode, goto the git lens view, open the commit tree view. Notice it's empty.

You'll have to hit the 'refresh icon' on the right of its title bar to populate it correctly. This was not the case a couple weeks ago.

(Thanks for your great product nonetheless you guys!)

VS Code version: Code 1.58.2 (c3f1263, 2021-07-14T22:30:16.440Z)
OS version: Linux x64 5.7.1-050701-generic
Restricted Mode: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz (8 x 2851)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software skia_renderer: enabled_on video_decode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	1, 1, 1
Memory (System)	7.54GB (0.82GB free)
Process Argv	--unity-launch --crash-reporter-id 21723db9-c8ea-462f-a1b4-f9c26cd3f8a8
Screen Reader	no
VM	0%
DESKTOP_SESSION	ubuntu
XDG_CURRENT_DESKTOP	Unity
XDG_SESSION_DESKTOP	ubuntu
XDG_SESSION_TYPE	x11

Extensions (36)

Extension	Author (truncated)	Version
better-comments	aar	2.1.0
theme-verdandi	be5	2.0.1
leointeg	bol	0.1.16
bracket-pair-colorizer-2	Coe	0.2.1
vscode-clock	Com	0.0.1
vscode-markdownlint	Dav	0.42.1
vscode-eslint	dba	2.1.23
xml	Dot	2.5.1
gitlens	eam	11.6.0
tsl-problem-matcher	eam	0.4.0
prettier-vscode	esb	8.0.1
php-intellisense	fel	2.3.14
vscode-pull-request-github	Git	0.28.0
todo-tree	Gru	0.0.213
vscode-power-mode	hoo	2.2.0
rest-client	hum	0.24.5
svg	joc	1.4.9
git-graph	mhu	1.30.0
ecdc	mit	1.4.0
python	ms-	2021.6.944021595
vscode-pylance	ms-	2021.7.4
cpptools	ms-	1.5.1
vscode-typescript-tslint-plugin	ms-	1.3.3
vsliveshare	ms-	1.0.4583
debugger-for-chrome	msj	4.12.12
indent-rainbow	ode	7.5.0
material-icon-theme	PKi	4.8.0
LiveServer	rit	5.6.1
code-settings-sync	Sha	3.4.3
svg-preview	Sim	2.8.3
code-spell-checker	str	1.10.2
selectline-statusbar	tom	0.0.2
errorlens	use	3.3.1
vscodeintellicode	Vis	1.2.14
expand-selection-to-scope	vit	0.2.0
vscode-icons	vsc	11.5.0

(13 theme extensions excluded)

A/B Experiments

vsliv368cf:30146710
vsreu685:30147344
python383cf:30185419
pythonvspyt678:30270856
pythonvspyt602:30300191
vspor879:30202332
vspor708:30202333
vspor363:30204092
pythonvspyt639:30300192
pythontb:30283811
pythonvspyt551:30311712
vspre833:30321513
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscus158:30321503
pythonvsuse255:30340121
vscod805:30301674
pythonvspyt200cf:30331938
vscextlangct:30333562
binariesv615:30325510
vsccppwt:30329788
bridge0708:30335490

[alexr00]

@boltex I can repro the issue with the gitlens commits view but not with any other view, and as far as I can see the commit tree is just returning 0 children. Can you point me to another tree view where you also see this issue?

[boltex]

@alexr00 Thank you for your time and consideration!

I've investigated this last night to try and get to the bottom of it. Turns out I had an event tied to the change of visibility of the treeview, and if visible === true, then I launched a 'refresh root' of the tree, which seemed to 'glitch out' that said refresh cycle. (is it intended/normal?)

(I re-use the same instance of the tree provider for two instances of the tree view: one in the explorer panel, and another one in a view-container that My extension provides. And so I thought I had to refresh the tree manually if uncovered by the user, either by unfolding it or by switching to the other view-container.)

I've noticed that, if the treeview was never populated, vscode launches a 'refresh cycle' itself upon revealing a treeview. (i verified by adding console.logs in the 'getChildren' method of my treeview provider) And me also calling this._onDidChangeTreeData.fire(); was causing glitching in the treeview it seems, preventing it to refresh properly.

Workaround : I've solved it by debouncing my calls to this._onDidChangeTreeData.fire() by 80 milliseconds.

(perhaps I only should try to refresh if I know my tree structure has changed - instead of also refreshing when I detect a visibility change that tells me a treeview was uncovered / unfolded and made visible.)

I'll let you close this issue if you see fit, as I'm not sure anymore if it's actually a bug that calling the refresh-root procedure as it's actually already refreshing bugs the treeview by not refreshing at all.

Many thanks again for your attention to the issue I raised! You Rock!! :)

[alexr00]

Thanks for the investigation @boltex!

I'll take some time to make sure the behavior you're seeing is intended before closing.

[boltex]

Sidenote: I wonder if this is related to #127204 (which is a duplicate of #110450) ... Which is the one big remaining bug in treeviews/sidebar that makes extensions somewhat look 'buggy'... :/