Explorer scrolls vertically when expanding folders

[jacobweber]

Issue Type: Bug

When I expand a folder by double-clicking it or clicking it and pressing the right arrow, it used to keep the selected folder in the same vertical position, and expand its contents below it.

In the most recent release, it started behaving differently. It scrolls the explorer down vertically, so that more of the folder's contents are visible.

I think we should have a setting to turn this off; I personally find it disorienting.

VS Code version: Code 1.44.0 (2aae1f26c72891c399f860409176fe435a154b13, 2020-04-08T08:23:56.137Z) OS version: Darwin x64 18.7.0

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz (8 x 2300)| |GPU Status|2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
viz_display_compositor: enabled_on
viz_hit_test_surface_layer: disabled_off_ok
webgl: enabled
webgl2: enabled| |Load (avg)|2, 2, 2| |Memory (System)|16.00GB (0.71GB free)| |Process Argv|-psn_0_106522| |Screen Reader|no| |VM|0%|

Extensions (28)

Extension|Author (truncated)|Version ---|---|--- project-manager|ale|10.11.0 vscode-intelephense-client|bme|1.3.11 npm-intellisense|chr|1.3.0 dart-code|Dar|3.9.1 mustache|daw|1.1.1 vscode-eslint|dba|2.1.2 gitlens|eam|10.2.1 vscode-npm-script|eg2|0.3.11 vscode-powertools|ego|0.58.0 php-debug|fel|1.13.0 vscode-favorites|how|1.4.0 svn-scm|joh|2.10.6 vscode-apache|mrm|1.2.0 python|ms-|2020.3.71659 remote-ssh|ms-|0.51.0 remote-ssh-edit|ms-|0.51.0 debugger-for-chrome|msj|4.12.6 java|red|0.59.1 vscode-yaml|red|0.7.2 vscode-hexdump|sle|1.7.2 slack|soz|0.0.14 vscodeintellicode|Vis|1.2.6 vscode-java-debug|vsc|0.25.1 vscode-java-dependency|vsc|0.9.0 vscode-java-pack|vsc|0.8.1 vscode-maven|vsc|0.21.2 sync-rsync|vsc|0.36.0 jinja|who|0.0.8

[isidorn]

I can not reproduce this. Can you reproduce using Visual Studio Code Insiders https://code.visualstudio.com/insiders/ Can you provide a gif / video showing this?

[jacobweber]

Here's a quick GIF where I click the node_modules expander and it moves node_modules to the top:

[isidorn]

I can not reproduce this. Can you reproduce using Visual Studio Code Insiders https://code.visualstudio.com/insiders/ Can you share your reprository for which you can alwasy repro this

[jacobweber]

I do see it in Insiders as well. After some more testing, I found that it doesn't happen when you first open the project. But try this:

1. Open a project with a large folder like node_modules.
2. Expand the folder. It will stay in its previous position.
3. Scroll down, and click one of the folder's contents that was previously scrolled out of view.
4. Press the left arrow key once to go back to node_modules.
5. Press the left arrow key again to collapse node_modules.
6. Now press the right arrow key to expand node_modules. This time it will scroll down.

[isidorn]

I can reproduce using your steps in the last comment. However I believe that is desired behavior In step 4. it reveals node_modules all the way at the top, so you can see as much children as possible Step 5 it shows it where it can since the tree is no longer scrollable Step 6 it preservers the scroll postiion from 4 the last time you had a scroll bar

In what exect steps are you saying it behaves unexpected? Also assigning to @joaomoreno since this is tree behavior.

[joaomoreno]

I must say it's a little bit strange, though I understand why it occurs: the list attempts to preserve the old scroll top, even when it "lost it" due to changes in height.

This is indeed a new behavioral change, introduced in https://github.com/microsoft/vscode/commit/1d76800a9e4013ab8320042a73eda26fe4d28a10. @alexdima any thoughts? Maybe we option it?

[isidorn]

IMHO this is not so unexpected and breaking and I would leave the current behavior and potentialy introduce an option in the future.

[jacobweber]

My arguments for fixing it (or at least making it optional) would be:

• It's inconsistent; you don't expect steps 2 and 6 to behave differently, but they do.
• It's different from how other tree views work, like the Finder or Eclipse.
• It's disorienting when the view keeps moving around.

[bpasero]

I am seeing this every once in a while, but harder to repro. Would be good to get a fix imho.

[jacobweber]

Thanks for the fix!