Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reveal Active File in Side Bar command is unreliable #77106

Closed
mgabeler-lee-6rs opened this issue Jul 10, 2019 · 9 comments
Closed

Reveal Active File in Side Bar command is unreliable #77106

mgabeler-lee-6rs opened this issue Jul 10, 2019 · 9 comments
Assignees
Labels
bug Issue identified by VS Code Team member as probable bug file-explorer Explorer widget issues verified Verification succeeded
Milestone

Comments

@mgabeler-lee-6rs
Copy link

Issue Type: Bug

  1. Open a workspace in vscode
  2. Collapse everything in the side bar
  3. Open a file in the workspace via some means other than clicking in the side bar
  4. Issue the Reveal Active File in Side Bar command

What happens for me:

Sometimes it works. Often however it only opens up some of the folder layers "on the way to" the file, and then stops before actually revealing the file.

For example, if my file is project1/a/b/c.ts, it might expand project1/a, but not project1/a/b so that it can show c.ts

VS Code version: Code 1.36.1 (2213894, 2019-07-08T22:55:08.091Z)
OS version: Linux x64 4.19.0-5-amd64

This was happening in 1.36.0, and 1.35.x too. My memory is uncertain if it was happening before that.

System Info
Item Value
CPUs Intel(R) Core(TM) i7-8850H CPU @ 2.60GHz (12 x 4000)
GPU Status 2d_canvas: enabled
flash_3d: enabled
flash_stage3d: enabled
flash_stage3d_baseline: enabled
gpu_compositing: enabled
multiple_raster_threads: enabled_on
native_gpu_memory_buffers: disabled_software
oop_rasterization: disabled_off
protected_video_decode: unavailable_off
rasterization: disabled_software
skia_deferred_display_list: disabled_off
skia_renderer: disabled_off
surface_synchronization: enabled_on
video_decode: unavailable_off
viz_display_compositor: disabled_off
webgl: enabled
webgl2: enabled
Load (avg) 1, 1, 1
Memory (System) 30.92GB (6.81GB free)
Process Argv --unity-launch
Screen Reader no
VM 0%
Extensions (17)
Extension Author (truncated) Version
markdown-preview-github-styles bie 0.1.6
bracket-pair-colorizer-2 Coe 0.0.28
vscode-markdownlint Dav 0.28.0
vscode-eslint dba 1.9.0
EditorConfig Edi 0.13.0
vscode-npm-script eg2 0.3.8
beautify Hoo 1.5.0
bash-ide-vscode mad 1.3.3
terraform mau 1.3.12
openapi-lint mer 1.0.3
vscode-docker ms- 0.7.0
Go ms- 0.11.4
debugger-for-chrome msj 4.11.6
vscode-yaml red 0.4.1
vscode-nginx sha 0.6.0
html-preview-vscode tht 0.2.5
reflow-paragraph Tro 1.3.0

(1 theme extensions excluded)

@isidorn
Copy link
Contributor

isidorn commented Jul 10, 2019

@mgabeler-lee-6rs Thanks for reporting this.
When you get this, if you F1 > developer tools > debug console > Do you see some error?

Can you try to get exact reproducable steps, we are very interested in hunting this bug down?
fyi @joaomoreno

@isidorn isidorn added file-explorer Explorer widget issues info-needed Issue requires more information from poster and removed new release labels Jul 10, 2019
@mgabeler-lee-6rs
Copy link
Author

As far as exact steps, I haven't found any strong correlation for when it does vs. does not work. But I can provide one small more behavioral observation: if it fails on the first try, if I hit the command a second time it seems to always work on the retry.

I did notice an error in the console when it just repro'd on me though:

  ERR Data tree node not found: [object Object]: Error: Data tree node not found: [object Object]
    at X.getDataNode (file:///usr/share/code/resources/app/out/vs/workbench/workbench.main.js:968:904)
    at X.<anonymous> (file:///usr/share/code/resources/app/out/vs/workbench/workbench.main.js:967:201)
    at Generator.next (<anonymous>)
    at file:///usr/share/code/resources/app/out/vs/workbench/workbench.main.js:35:460
    at new Promise (<anonymous>)
    at n (file:///usr/share/code/resources/app/out/vs/workbench/workbench.main.js:35:237)
    at X.expand (file:///usr/share/code/resources/app/out/vs/workbench/workbench.main.js:966:945)
    at e.<anonymous> (file:///usr/share/code/resources/app/out/vs/workbench/workbench.main.js:5357:202)
    at Generator.next (<anonymous>)
    at r (file:///usr/share/code/resources/app/out/vs/workbench/workbench.main.js:35:293)

@mgabeler-lee-6rs
Copy link
Author

Some more observations on the failure mode:

  1. The error quoted above happens every time it fails and never when it succeeds
  2. Thus far it's always getting stuck after opening the "second" layer -- i.e. given my multi-folder workspace, it opens the top level folder, and one folder below that, and then gets stuck
  3. It never seems to fail on a given file if it has succeeded before on the current open of the workspace
  4. I can get it to reliably fail if I collapse all the side bar folders, close the workspace, open it again, and invoke the reveal command
  5. The behavior is unchanged if I launch vscode with all extensions disabled

@isidorn isidorn added this to the August 2019 milestone Jul 30, 2019
@isidorn isidorn removed the info-needed Issue requires more information from poster label Jul 30, 2019
@isidorn
Copy link
Contributor

isidorn commented Jul 30, 2019

@mgabeler-lee-6rs thanks for providing more details, assignig to August to investigate then.
fyi @joaomoreno

@mgabeler-lee-6rs
Copy link
Author

This is probably no surprise to anyone, but confirming this issue is still present unchanged in 1.37.0

@isidorn
Copy link
Contributor

isidorn commented Aug 21, 2019

@mgabeler-lee-6rs thanks for great repro steps, I could finally reproduce the issue.
The problem was that here we were expanding the tree elements in a chain.
And it looks like the tree returns from the expand as soon as the element is expanded and its children get fetched. However that moment seems to early to call expand for one of its children. This feels like an issue in the tree thus ping @joaomoreno

In the meantime as a workaround I have added a timeout of 0 between expands that seems to fix the issue.

To verify: you can take vscode insiders from Thursday and let us know if you still see the issue.

@isidorn isidorn added the bug Issue identified by VS Code Team member as probable bug label Aug 21, 2019
@mgabeler-lee-6rs
Copy link
Author

Thanks! I'll take a look at that build when it comes out and confirm.

@mgabeler-lee-6rs
Copy link
Author

Installed code-insiders version 1.38.0-1566471633 and confirmed the fix is working, thanks!

@isidorn
Copy link
Contributor

isidorn commented Aug 23, 2019

Ok, adding verified label.
Though this introduced a slight delay / jarring effect in revealing. For this milestone let's go with this approach and next milestone we can see if there is something better than the sily timeout.
fyi @bpasero

@isidorn isidorn added the verified Verification succeeded label Aug 23, 2019
@vscodebot vscodebot bot locked and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bug Issue identified by VS Code Team member as probable bug file-explorer Explorer widget issues verified Verification succeeded
Projects
None yet
Development

No branches or pull requests

2 participants