File Explorer folders collapse after VS Code loses focus

[desmondw]

Issue Type: Bug

We have a workspace that uses multi-root workspaces like so:

  "folders": [
    { "path": "client", "name": "client" },
    { "path": "damage-prevention", "name": "server" },
    { "path": ".", "name": "<root>" }
  ],

As you can see, the first two folders are also encompassed in the third. I believe the intent was to have quick references to needed areas while also being able to reference them by a variable name in the .code-workspace settings.

Anyway, this causes an issue with the File Explorer focusing. Normally when you switch between files you have opened, you can move between the files and it focuses on the file in the File Explorer. This works fine with our set up. Anything that is under the subfolders opens up that structure in the File Explorer.

If however, you have one of the subfolder files focused, when you tab out and back in to VS Code it will collapse the subfolder, causing you to lose track of where you were in the file structure.

I've tried to narrow down why this happens, and I can assure it's due to the subfolder strutcturing, but couldn't find out more than that. The problem occurs often, but not always. I tried to experiment with which files I was accessing, or which folders in the file explorer I had open before tabbing out but I could not diagnose further.

This is on macOS Big Sur.

VS Code version: Code 1.61.2 (Universal) (6cba118ac49a1b88332f312a8f67186f7f3c1643, 2021-10-19T15:49:28.381Z) OS version: Darwin x64 20.6.0 Restricted Mode: No

System Info

|Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz (16 x 2300)| |GPU Status|2d_canvas: enabled
gpu_compositing: enabled
metal: disabled_off
multiple_raster_threads: enabled_on
oop_rasterization: enabled
opengl: enabled_on
rasterization: enabled
skia_renderer: disabled_off_ok
video_decode: enabled
webgl: enabled
webgl2: enabled| |Load (avg)|4, 3, 2| |Memory (System)|32.00GB (0.10GB free)| |Process Argv|--crash-reporter-id 486cf40d-eaf5-4082-b171-b10812236b33| |Screen Reader|no| |VM|0%|

Extensions (40)

Extension|Author (truncated)|Version ---|---|--- vscode-icalendar|af4|1.0.1 increment-selection|alb|0.2.0 Bookmarks|ale|13.2.2 rtf|ale|2.3.0 vscode-sqlite|ale|0.13.0 vscode-django|bat|1.6.0 vscode-tailwindcss|bra|0.7.1 vscode-eslint|dba|2.2.2 gitlens|eam|11.6.1 prettier-vscode|esb|9.0.0 duplicate|gee|1.0.2 gc-excelviewer|Gra|3.0.44 vscode-graphql|Gra|0.3.18 pico8-vscode|joh|0.0.1 vscode-leetcode|Lee|0.18.0 restructuredtext|lex|166.0.0 auto-dark-mode|Lin|0.1.7 rainbow-csv|mec|1.9.1 dotenv|mik|1.0.1 vscode-exec-node|mir|0.5.4 vscode-docker|ms-|1.17.0 python|ms-|2021.10.1365161279 vscode-pylance|ms-|2021.10.3 jupyter|ms-|2021.9.1101343141 jupyter-keymap|ms-|1.0.0 jupyter-renderers|ms-|1.0.3 remote-containers|ms-|0.202.5 cpptools|ms-|1.7.1 vscode-typescript-next|ms-|4.5.20211031 debugger-for-chrome|msj|4.13.0 vetur|oct|0.35.0 ActiveFileInStatusBar|Ros|1.0.3 code-settings-sync|Sha|3.4.3 mdx|sil|0.1.0 vscode-autohotkey|sle|0.2.2 vscode-open-in-github|sys|1.15.0 vsfire|tob|1.4.1 pdf|tom|1.1.0 luna-paint|Tyr|0.10.0 vscodeintellicode|Vis|1.2.14 (5 theme extensions excluded)

[gjsjohnmurray]

Please use the Start Extension Bisect command to investigate whether the problem is being caused by one of your extensions.

[desmondw]

@gjsjohnmurray I used the Start Extension Bisect command and verified the issue occurred with all extensions disabled.

[desmondw]

It generally appears as if (with two files open in editor, from a subfolder workspace):

• if I have the parent folder workspace expanded in the sidebar and unfocus VS Code, it will collapse all other subfolder workspaces when VS Code gains focus
• if I collapse all folders, expand the parent folder, collapse the parent folder, then expand a subfolder, then unfocus VS Code... the subfolder will collapse when VS Code gains focus
• if I collapse all folders, expand the parent folder, collapse the parent folder, then tab the next open file (it will expand it's position in the subfolder), then unfocus VS Code, then focus VS Code, the subfolder will collapse
• if I collapse all folders, expand the parent folder, collapse the parent folder, unfocus VS Code, focus VS Code, then tab the next open file (it will expand it's position in the subfolder), then unfocus VS Code, then focus VS Code, the subfolder will collapse when VS Code gains focus
• if I collapse all folders, expand the parent folder, collapse the parent folder, unfocus VS Code, focus VS Code, unfocus VS Code, focus VS Code, then tab the next open file (it will expand it's position in the subfolder), then unfocus VS Code, then focus VS Code, the subfolder WILL NOT collapse when VS Code gains focus

Note that the two last items are identical except for one more round of unfocusing and refocusing VS Code, but had different results. This appeared to be consistent and is probably a good place to start in debugging this.

[bpasero]

One change @isidorn did (as far as I can remember) is to refresh the explorer everytime the window gets focus, to circumvent missing file events.

[desmondw]

The event that collapses the file explorer folders can also be triggered on a file save (only if there are changes).

[BenCheung0422]

This also happened on me, it is so annoying. The situation is shown as the below. I have some workspace folders like: example, foo and bar. The folders' structure:

example
├─ foo
└─ bar

when I have some folders which are not expanded in "example" workspace tree, but expanded in foo or bar, the folders will be collapsed after refocusing. Like (workspace folders):

example     foo       bar
├─foo       ├─fooo    ├─a
└─bar       └─foooo   │  └─aa
    ├─a               └─b
    └─b

Will be collapsed as:

example     foo    bar
├─foo              ├─a
└─bar              └─b
    ├─a
    └─b

I don't want them be collapsed like that.

[JacksonKearl]

Can you try setting skipRefreshExplorerOnWindowFocus to true (it's a hidden setting, you'll need to edit package.json directly) and see if this reproduces in next insiders?

[mckravchyk]

Started happening to me after a recent update to 1.65.1 on Linux I don't know what was the previous version I was using. This bug is very annoying and completely breaks the flow of work, Let's say you have /src/lib/something.ts opened. The file is highlighted as it should, until the window loses focus. Then /lib will be collapsed and the current file not highlighted, not even the collapsed /lib folder will be highlighted. I remember there used to be a similar bug, then it was fixed and now it's back again.

Edit: I no longer see it occur. I think this occurred because the folder had 2 instances in the workspace: it was a folder directly added to the workspace, as well as a subfolder of another workspace folder - perhaps such a scenario causes the bug to occur.

[chan-vince]

Can you try setting skipRefreshExplorerOnWindowFocus to true (it's a hidden setting, you'll need to edit package.json directly) and see if this reproduces in next insiders?

@JacksonKearl Could you please let me know where the package.json file is? Or how to enable hidden settings like this? Thanks 👍

[gjsjohnmurray]

@chan-vince see https://code.visualstudio.com/docs/getstarted/settings#_settingsjson

[chan-vince]

@gjsjohnmurray Thanks - didn't realise it was the same thing as the settings.json file.

I've been having this explorer folder closing issue for a while now on MacOS, where it was happening virtually 100% of the time in my multi-root workspace of about 20 or so roots.

Since adding this setting I haven't seen it happen yet, so I can tentatively say it's done something, if not fixed entirely. Thanks!

[gjsjohnmurray]

Thanks - didn't realise it was the same thing as the settings.json file

I think that was a typo by @JacksonKearl

Good to hear that the setting has apparently helped.

[desmondw]

Can you try setting skipRefreshExplorerOnWindowFocus to true

I've tried setting this both in my settings.json and the settings in my *.code-workspace file and in both cases it tells me it's an invalid configuration, which makes sense as it doesn't follow the same namespacing style:

What am I missing here?

[gjsjohnmurray]

@desmondw you can ignore that message. It's a consequence of this being what @JacksonKearl called a "hidden setting".

Does it make any difference to your problem? If not, what VS Code version are you running?

[desmondw]

@gjsjohnmurray I tried it in both regardless, and the issue still presented. Here's my current version:

Version: 1.66.1 (Universal)
Commit: 8dfae7a5cd50421d10cd99cb873990460525a898
Date: 2022-04-06T14:49:47.400Z
Electron: 17.2.0
Chromium: 98.0.4758.109
Node.js: 16.13.0
V8: 9.8.177.11-electron.0
OS: Darwin x64 21.3.0

No other details should've changed since the original post.

[JacksonKearl]

Note you'll need to reload the window for the setting to take effect. It's a debugging measure I added to help understand the root cause of the recent issues here.

[desmondw]

I've restarted VS Code to effect the config change as @JacksonKearl suggested after adding it to the workspace and it appears to work.

I ran through my detailed scenarios in my second comment and was not able to trigger them. I'm hesitant to make an "I'm cured!" statement since its occurrence is finicky, but this seems to have worked.

[chan-vince]

Sorry to be the bearer of bad news, but it appears to still be happening for me. Honestly I can't see a pattern in the behaviour, so I can't definitively say it was fixed before, and then started happening again 😢

[desmondw]

Unfortunately I have also noticed it still occurring as well.

[JacksonKearl]

To be clear, is it the case that applying the setting originally solved this all of the time and now it doesn't solve it ever? Or is it that with the setting reduced the frequency of this happening but it still sometimes occurs? If the latter, is there any more specific reproductions steps for when it does occur?

[desmondw]

@JacksonKearl It appears to inconsistently help.

Right now it's working for me, and I verified with my above examples it has resolved them. Removing the config options causes the bug to reproduce with the examples, and adding the config back in once again resolves it.

However during work I have also noticed the issue happening. I have not run the same examples above at that time to tell if it's a different flow that causes it or something else. I'll try to test next time it occurs, but it only seems to strike when I'm in flow. :/

[chan-vince]

Agree with @desmondw, but unfortunately I can't give much more detail.

When I remove the config option, I get the closing issue perhaps 95% of the time, whereas adding the option reduces it to perhaps 10% of the time. Obviously these numbers are just guestimates.

It's not just when the window loses/regains focus either - I see this happening when switching between files, either by clicking in the Explorer, or clicking to a tab if its already open.

For now I can't see any pattern at all, and because it's appears to be completely random I can't offer any repro steps..but perhaps I'll start noting down when it happens to see if that shows anything.

[erikfriberg]

I have the same issue, the setting that’s mentioned here seems to help a bit, but my suspicion is that the problem occurs when I’m running a watch task that builds to a "dist" folder upon save. Perhaps the dist folder interferes with my folder hierarchy? (even though the folder in question is not expanded and therefore shouldn’t really trigger any visual change)