Open Workspace while another Workspace is open doesn't work. #3061
Comments
|
This is very strange. I was able to reproduce locally. Opening a workspace is not working. There are no logs in the console. And running code-server with Screen.Recording.2021-04-07.at.10.35.00.AM.movThis is definitely a bug. Thank you for reporting! We'll investigate. |
|
Update: There was no any unusual log on my side either. (On both server/client with |
|
Finally got an error on the client-side on 3.9.3 fe2dc2d when trying to press OK button on the Open Workspace. |
|
Interesting! Well at least this is a starting point :) Thanks for the update @SJang1 ! |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days. |
|
(still presents |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no activity occurs in the next 5 days. |
|
(still presents |
|
@jsjoeio Has anyone had time to look at this? I see similar behavior when using "Open workspace from file." Sometimes, it loads, but it frequently hangs with the explorer trying to refresh forever. I have seen the same behavior when trying to use any of the workspace-switching extensions like these:
|
|
In my case, it appears that this might work with a single browser, but it exhibits the issue immediately when two browsers have the code-server UI open and the second one tries to load a new workspace file. |
|
This might be related to: #2161 Although the details seem a bit different. I can see terminals and windows in general but can not open a new workspace from the other browser. cc/ @code-asher |
|
I think I am seeing the same thing. In my case I opened a workspace file, copied the URL, then pasted that into a new tab and in the new tab the file explorer, git, and debug are empty or hung for me. Terminal and extensions are fine. Search works, interestingly, and I can open files from there. I was not able to reproduce in Codespaces. I think there they run separate instances for each connection so that might have something to do with it. In any case it probably means we will need to patch it from here. I might be able to take a deeper look in a couple weeks. |
|
@code-asher That would be great. If there is any additional information that I can gather, please let me know. Getting this fixed would resolve a pretty significant issue that we are having currently when using |
|
I've love to see this fixed - we'd also be happy to sponsor the fix, if that helps. |
|
It looks like I am not going to be able to get to this in the next two weeks, and I am going to be away from my keyboard for a few weeks after that, but I will try to check in periodically in case someone takes this up and submits a PR. If not I will see about scheduling some time for it after I get back. |
Understood. Thank you @code-asher Some additional details While searching for a workaround, I was also able to reproduce this issue just by starting up
[Unit]
Description=code-server
After=network.target
[Service]
# This environment variable is set to "trick" the Golang extension
# see: https://github.com/golang/vscode-go/issues/1246
Environment="CLOUD_SHELL=true"
Type=exec
WorkingDirectory=~
ExecStart=/usr/bin/code-server ./.vscode/default.code-workspace
Restart=always
User=%i
[Install]
WantedBy=default.target
{
"folders": [
{
"name": "project1",
"path": "/home/me/project1"
},
{
"name": "project2",
"path": "/home/me/project2"
},
],
"settings": {
"explorer.expandSingleFolderWorkspaces": false,
"explorer.fileNesting.enabled": false
}
}In this example, |
|
I cannot reproduce this problem in Gitpod's I tested this with:
Running this and then opening up a multi-root workspace work fine. Refreshing works fine, and opening the workspace up from another browser appears to work fine as well. |
|
This issue is definitely
|
My basic workflow from scratch: Update Code
❗ Usually checking out a tag (e.g Set version export VERSION='4.20.0-rc.1'Install dependencies yarnBuild code-server yarn build
yarn build:vscode
KEEP_MODULES=1 yarn releaseModify version npm version --prefix release "$VERSION"tmp=$(mktemp)
jq ".codeServerVersion = \"$VERSION\"" release/lib/vscode/product.json > "$tmp" && mv "$tmp" release/lib/vscode/product.json
chmod 644 release/lib/vscode/product.jsonBuild release packages yarn release:standalone
yarn test:integration
yarn packageThen, I deploy at https://coder.jupyter.b-data.ch/ (image See also https://coder.com/docs/code-server/latest/CONTRIBUTING |
|
Wow thanks! Yea, I was reading up, made my way through several errors. But it is faster to try your |
|
P.S.: Image |
|
@benz0li thank you for providing a release to test! I tried to put out a release candidate yesterday but for some reason the e2e test keeps failing...still looking into it. |
My pleasure.
No worries.
Thanks for all your efforts. Much appreciated – as always. |
|
Finally put up a release candidate. I would love to hear confirmation on whether the issue is resolved from anyone that was having the issue. |
|
Issue appears to be fixed for me after testing with multiple browsers and across workspace reloads. Thank you for the prompt resolution of this issue! Greatly appreciated! |
|
4.19.1-rc.1 is broken on mine.
4.19.0
4.19.1-rc.1
|
|
Let me test later thanks. How is a user supposed to retain their settings across machines then? |
Thank you.
@code-asher I can confirm that
Footnotes |
@bilogic How have you done this so far? |
|
@bilogic 'Folder settings' overwrite 'Workspace settings' overwrite 'Remote settings' (Machine settings) overwrite 'User settings' overwrite 'Default settings'. |
|
So what I understand about VSCode is:
Proposed new behavior
|
|
@code-asher what do you think? Should I start another issue for it? Thanks. |
@bilogic Yes, please. Please keep the following in mind:
code-server is not VS Code [+ Dev Container] but is instead similar to Codespaces.
IMHO not going to happen; Reverted by 09dd5fe |
|
Although I have not had the opportunity to test this fix yet, I am guessing that the fix (reverting the I'll add this to the new issue that @bilogic is starting. |
|
Oof, sorry about all this. When you edit user settings in VS Code web it saves the settings in browser storage, not on disk, so I was under the impression our patch was no longer doing anything. (Also we have issues like #4263 where the user settings on disk seem to be ignored.) It seems, though, it does still take effect, or at least partially;
Edit: I was pretty off on this, problem was an improper use of async globals that only manifested with enough delay fetching the settings, which happens when we move settings to the remote. Settings were always being stored correctly, no partial storage was involved. However, from a maintenance perspective it would be better to keep the patch removed, aligning us with upstream (which stores user settings in browser storage, see Codespaces for example), and for everyone to migrate from user settings to machine settings (basically just rename Then again, Microsoft caused the breaking change by changing the behavior from reading from disk to browser storage and they never major bumped, so maybe minor is fine. But since it only affects web maybe they were not very concerned about compatibility. I think when it comes to IDEs folks probably just always download the latest anyway so maybe semver does not have as much meaning as it would with a library or something. Or maybe VS Code uses the version as a way to document plugin API compatibility only, not other things like setting storage locations. |
'User Settings' are stored on disk and work just fine. Regarding #4263 see #4263 (comment).
I agree. I am happy to move from 'User Settings' to 'Remote Settings' (Machine Settings) should the patch be removed. Codespaces work exactly the same way.
|
|
Thank you for the input! So right now I think we are leaning toward keeping the patch removed and doing a major bump. I have a few hours left before the holidays so I might have to pick this back up on Monday, but I am going to just see if I can quickly get the old behavior working while still resolving this bug, just so we know what the alternative looks like. Maybe it will not be so bad... |
|
Just to be clear the behavior that we are using today, is writing a
{
"security.workspace.trust.enabled": false
}which I am pretty confident are not allowed to be set by any settings layer besides the If there is another reasonable way to do this so that these settings will be the default for any browser that opens up the |
|
I gave a summary + response on #6546, let's continue there shall we? |
And fix the workspace bug. It is caused by an issue with how some global variables are being used asynchronously and is exacerbated by the delay reading settings from the remote introduces. 1. The workspace is created and is marked as not initialized. 2. The configuration's change handler is triggered, and now initialization is complete. 3. The handler tries to set the global workspace variable to initialized but the workspace has not been set yet so we get an undefined error. 4. The workspace global is now set, but it is set to the old value with initialized still set to false. 5. Workspace is never marked as initialized until something else triggers the on change handler again. Fixes #3061, and closes #6546. My guess is this logic changed in one of the VS Code updates, introducing this async bug but never getting caught probably because for them the settings are always local thus minimal delay.
And fix the workspace bug. It is caused by an issue with how some global variables are being used asynchronously and is exacerbated by the delay reading settings from the remote introduces. 1. The workspace is created and is marked as not initialized. 2. The configuration's change handler is triggered, and now initialization is complete. 3. The handler tries to set the global workspace variable to initialized but the workspace has not been set yet so we get an undefined error. 4. The workspace global is now set, but it is set to the old value with initialized still set to false. 5. Workspace is never marked as initialized until something else triggers the on change handler again. Fixes #3061, and closes #6546. My guess is this logic changed in one of the VS Code updates, introducing this async bug but never getting caught probably because for them the settings are always local thus minimal delay.
@benz0li can I ask if these are still your build steps? Have build times increased significantly since then? |
Yes, these are still my build steps.
Yes, at least doubled, if not tripled. |
|
Thanks, I'm taking it up with vscode, hope they can do something about it. btw this might help apply patches to your insider builds. |
OS/Web Information
code-server --version: 3.9.2 109d2ceSteps to Reproduce
Expected
New workspace should open
Actual
Nothing happens
and it also
cd..s on the input area or saysPlease select a file.Screenshot
2021-04-07.10.32.19.mov
Notes
This issue can be reproduced in VS Code: No
At the video I attached has language that is not in English, but that is NOT why this happens.
The text was updated successfully, but these errors were encountered: