Skip to content

[Bug]: Source control UI is unresponsive starting from version 4.10+ #6153

New issue

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

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

Already on GitHub? # to your account

Closed
4 tasks done
maxorlovsky opened this issue Apr 19, 2023 · 16 comments
Closed
4 tasks done
Labels
bug Something isn't working triage This issue needs to be triaged by a maintainer

Comments

@maxorlovsky
Copy link

Is there an existing issue for this?

  • I have searched the existing issues

OS/Web Information

  • Web Browser: Chrome
  • Local OS: Windows
  • Remote OS: Debian
  • Remote Architecture: amd64
  • code-server --version: 4.11.0

Steps to Reproduce

  1. install code-server 4.11.0 using install shell script
  2. run code-server
  3. modify file
  4. enter source control and try to add file as "git add" through the UI, it is unresponsive. It's not only git add, but also revert and the whole UI for pull/push except git commit

Expected

git functionality as git add / git revert / git pull / git push should happen

Actual

UI is clickable but unresponsive and there are no logs showing in git terminal

Logs

No response

Screenshot/Video

No response

Does this issue happen in VS Code or GitHub Codespaces?

  • I cannot reproduce this in VS Code.
  • I cannot reproduce this in GitHub Codespaces.

Are you accessing code-server over HTTPS?

  • I am using HTTPS.

Notes

This does not happen in 4.9.1 version of the code-server, it started with version 4.10

@maxorlovsky maxorlovsky added bug Something isn't working triage This issue needs to be triaged by a maintainer labels Apr 19, 2023
@code-asher
Copy link
Member

code-asher commented May 1, 2023

I experimented with the 4.11.0 and 4.12.0 Docker images but had no luck reproducing. Does it only happen with a specific repository and if so is it something that can be shared?

@waschinski
Copy link

Same error here, running code-server on a Synology NAS. I noticed every time I click on some Git action like revert or adding a change, "extensions are being activated" is displayed but nothing happens. I have found no errors in the logs.

Can also confirm reverting to 4.9.1 it's working again.

Maybe it has to do with the extension host?

@maxorlovsky
Copy link
Author

No it's not public unfortunately and can't be shared. I don't think it's something related to a project I tried with multiple projects.

@code-asher
Copy link
Member

code-asher commented May 9, 2023 via email

@maxorlovsky
Copy link
Author

No, command line is unaffected. I can easily do git pull / git commit / git push.
Git log have nothing unfortunately. Is there some kind of verbose command that can be use to output more logs?

@code-asher
Copy link
Member

I think if code-server is launched with --log debug (or --log trace) that will propagate to extensions but I am not sure.

@code-asher
Copy link
Member

code-asher commented May 9, 2023

Oh interesting, looks like there is a log level setting for git specifically as well (configured through the settings panel in code-server or through the json file).

@code-asher
Copy link
Member

code-asher commented May 9, 2023

Wild guess, I wonder if it is trying to prompt for credentials but unable to show the popup for whatever reason. Except why would this affect revert or add? So maybe not.

@code-asher
Copy link
Member

code-asher commented May 9, 2023

Another wild guess, are you seeing issues with memory consumption? Saw an issue once where running git gc resolved a freeze when source control was used.

Edit: although, if the problem does not manifest in < 4.10 then probably unrelated.

@Anshuldubey0602
Copy link

Same issue with version 4.7.1

@bilogic
Copy link
Contributor

bilogic commented Nov 3, 2023

Is it only the Source Control that is affected?

I was on 4.13.0 for a long time, all good, but recently upgraded to 4.17.1 and 4.18.0 and running into a similar issue where loading of Source Control and extensions do not complete.

The clocks stay there forever, Source Control loading is incomplete and will never complete + there is no Activating extensions ... at the status bar. The way I would describe it is Extensions crashed without errors

vscode1
vscode2
vscode3

@code-asher
Copy link
Member

@bilogic I have seen a similar issue with #3061 but I am not sure it is the same thing.

@bilogic
Copy link
Contributor

bilogic commented Nov 16, 2023

@code-asher thanks I think they are the same problem, and this thread has a more accurate description of the problem

@bilogic
Copy link
Contributor

bilogic commented Nov 20, 2023

More observations:

  1. When facing this issue, Source Control becomes broken
  2. However, saving a file etc remains functional

This leads me to think that perhaps something in the "Trust workspace" code is broken?

code-asher added a commit that referenced this issue Nov 20, 2023
The main goal of this patch was to make user settings stored on disk
instead of in the browser, but this stopped working some time ago.  Not
only that but it is causing a bug where a workspace will not fully open.

A secondary goal was to fix the Vim extension but the extension appears
to work just fine without this change now (both the server and browser
versions).

This patch is not useful anymore anyway because there are remote-level
settings that *do* get stored on disk and can be used instead of
user-level settings when necessary.

Fixes #3061, and possibly #6153.
code-asher added a commit that referenced this issue Nov 20, 2023
The main goal of this patch was to make user settings stored on disk
instead of in the browser, but this stopped working some time ago.  Not
only that but it is causing a bug where a workspace will not fully open.

A secondary goal was to fix the Vim extension but the extension appears
to work just fine without this change now (both the server and browser
versions).

This patch is not useful anymore anyway because there are remote-level
settings that *do* get stored on disk and can be used instead of
user-level settings when necessary.

Fixes #3061, and possibly #6153.
@bilogic
Copy link
Contributor

bilogic commented Nov 28, 2023

This appears to have been fixed by 4.19.1-rc.2.

Ever since upgrading from 4.13.0, I faced the issue about 50% of the time when I open another workspace.

I have been swapping workspaces > 20 times on 4.19.1-rc.2 and not faced it once,

@code-asher
Copy link
Member

Thank you for confirming! 4.19.1 is now out.

yiliang114 pushed a commit to yiliang114/code-server that referenced this issue Jan 23, 2025
The main goal of this patch was to make user settings stored on disk
instead of in the browser, but this stopped working some time ago.  Not
only that but it is causing a bug where a workspace will not fully open.

A secondary goal was to fix the Vim extension but the extension appears
to work just fine without this change now (both the server and browser
versions).

This patch is not useful anymore anyway because there are remote-level
settings that *do* get stored on disk and can be used instead of
user-level settings when necessary.

Fixes coder#3061, and possibly coder#6153.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
bug Something isn't working triage This issue needs to be triaged by a maintainer
Projects
None yet
Development

No branches or pull requests

5 participants