Repository navigation
Open Workspace while another Workspace is open doesn't work. #3061
Description
OS/Web Information
- Web Browser: Firefox 87.0
- Local OS: M1 Macbook Air, MacOS 11.2.3
- Remote OS: Ubuntu 20.04
- Remote Architecture: x64
code-server --version: 3.9.2 109d2ce
Steps to Reproduce
- Open and work on the workspace
- Click menu bar left top corner -> File -> Open Workspace
- Try to open
Expected
New workspace should open
Actual
Nothing happens
and it also cd..s on the input area or says Please 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.
Activity
jsjoeio commentedon Apr 7, 2021
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
--log debugshows no unusual messages.Screen.Recording.2021-04-07.at.10.35.00.AM.mov
This is definitely a bug. Thank you for reporting! We'll investigate.
SJang1 commentedon Apr 8, 2021
Update: There was no any unusual log on my side either. (On both server/client with
--log debuglike that video in the comment.)SJang1 commentedon Apr 9, 2021
Finally got an error on the client-side on 3.9.3 fe2dc2d when trying to press OK button on the Open Workspace.
No unusual logs on the server-side even for now.
jsjoeio commentedon Apr 12, 2021
Interesting! Well at least this is a starting point :) Thanks for the update @SJang1 !
stale commentedon Oct 9, 2021
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.
SJang1 commentedon Oct 10, 2021
(still presents
stale commentedon Apr 8, 2022
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.
SJang1 commentedon Apr 9, 2022
(still presents
43 remaining items
bilogic commentedon Nov 22, 2023
@code-asher what do you think? Should I start another issue for it? Thanks.
benz0li commentedon Nov 22, 2023
@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
👉 Same behaviour as Codespaces now. Use 'Remote settings' (Machine settings) instead.
spkane commentedon Nov 22, 2023
Although I have not had the opportunity to test this fix yet, I am guessing that the fix (reverting the
local storage patch) actually removed another feature that we rely on in our environment, the ability to set some default User settings which will be pre-set in VScode, without the user needing to set them in each and every browser they open (home, work, etc). This was a core reason we picked code-server over gitpod's implementation.I'll add this to the new issue that @bilogic is starting.
code-asher commentedon Nov 22, 2023
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;
perhaps it uses the disk due to our patch under certain conditions (startup maybe), but under other conditions (using the settings menu, for example) it uses browser storage. I would need to experiment more. This incomplete patching is, I think, the cause of this bug.An alternative, which would preserve the existing behavior, would be to dig into the code and patch it more fully so it uses the disk everywhere instead of browser storage, but I have no idea how extensive this patching will be.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
User/settings.jsontoMachine/settings.json), but at the same time I am reluctant to release a breaking change especially with a minor or patch bump. We could major bump. Definitely need to make this all clear in the changelog and release notes if we keep the patch removed, regardless of how we bump.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.
benz0li commentedon Nov 22, 2023
'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.
Yes, this should be a new major version.code-asher commentedon Nov 22, 2023
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...
spkane commentedon Nov 23, 2023
Just to be clear the behavior that we are using today, is writing a
settings.jsonfile to:/home/user/.local/share/code-server/Userwhich contains various settings, including things like:{ "security.workspace.trust.enabled": false }which I am pretty confident are not allowed to be set by any settings layer besides the
Userone. I do not care if the User changes them after the fact, but I absolutely want to set various settings defaults since our instances are internal, used for very specific use cases and are not used by the general public.If there is another reasonable way to do this so that these settings will be the default for any browser that opens up the
code-serverURL, I am happy to change over to that method. Otherwise, I may be stuck onv4.16.1.for awhile.bilogic commentedon Nov 23, 2023
I gave a summary + response on #6546, let's continue there shall we?
Add back local storage patch
Add back local storage patch
bilogic commentedon Jul 10, 2024
@benz0li can I ask if these are still your build steps? Have build times increased significantly since then?
benz0li commentedon Jul 10, 2024
Yes, these are still my build steps.
Yes, at least doubled, if not tripled.
bilogic commentedon Jul 11, 2024
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.
Delete local storage patch
Add back local storage patch