search

coder / code-server

VS Code in the browser
https://coder.com
MIT License
67.63k stars 5.55k forks source link

Store state on remote instead of browser #4212

Open abhay-ranawat opened 2 years ago

abhay-ranawat commented 2 years ago

Edit by @code-asher: Storing the state in the browser has (at least) the two following problems:

  1. If you switch to another browser you have to open and configure everything all over again (what this issue was originally about).
  2. It is impossible to seed the initial state like you could in native VS Code by writing to the JSON state file.

Original issue content follows.

OS/Web Information

Steps to Reproduce

  1. Open a new code server instance in browser and make some changes (eg : hide remote host).
  2. Open the same instance in incognito tab.
  3. The changed made above will not be reflected, and you have to make those changes again.

Expected

Till v3.11 the state of code-server was maintained across browsers.

Actual

The state is saved local storage instead of server and hence the changes does not reflect on browser changes.

Notes

scope === StorageScope.GLOBAL ? 'global' : this.payload.id; it is in workbench.web.api.js.map Perhaps it's related to where the state is saved? From discussion : https://github.com/cdr/code-server/discussions/4185

jsjoeio commented 2 years ago

Thanks for opening this up @abhay-ranawat! We'll have to investigate

benz0li commented 2 years ago

I have the same issue.

It would be great to have this resolved with v3.12.1.

jsjoeio commented 2 years ago

It would be great to have this resolved with v3.12.1.

That's unlikely to happen given our bandwidth (just setting expectations) but at least we know multiple folks are experiencing this issue.

abhay-ranawat commented 2 years ago

It would be great to have this resolved with v3.12.1.

That's unlikely to happen given our bandwidth (just setting expectations) but at least we know multiple folks are experiencing this issue.

Given the changes made in code, everyone should face it (AFAIK) only few might be noticing it.

benz0li commented 2 years ago

Agreed. I noticed it because I regularly delete all cookies and site data that the browser stores. I don't mind setting an exception for the domains on which code-server is deployed, though.

It doesn't matter whether the state is stored in ~/.local/share/code-server/User/state or the browser 's site data - but it should be documented, which is the case. 👉 In order to reset the state, one has to either delete ~/.local/share/code-server/User/state or clear the browser's site data.

ℹ️ I had to delete folder ~/.local/share/code-server/User/state after I moved from debian:buster to debian:bullseye, because e.g. the new Python version was not displayed correctly in v3.10.2.

stale[bot] commented 2 years ago

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.

benz0li commented 2 years ago

As for stale bot see https://drewdevault.com/2021/10/26/stalebot.html: This is a terrible, horrible, no good, very bad idea.

code-asher commented 2 years ago

https://drewdevault.com/2021/10/26/stalebot.html

That was a great read. In the past we would periodically run through old issues and close out ones that no longer were applicable (this is because things can change a lot when we update Code versions) and the stale bot moves that burden off us to those who opened the issue. We could just leave them alone but we felt like keeping issues up to date was part of good repository maintenance. Maybe there is a better solution, like labeling issues that are on the Code side with something like upstream and then adding stale or revalidate or something to those when we update Code?

For the browser state I did look into moving it back to the remote file system but it looked non-trivial so I abandoned that effort since we generally try to avoid patches that deviate too aggressively from mainline.

There might be a clean way to do it with a bit more investigation though or maybe upstream would be receptive of a change to make this behavior configurable.

code-asher commented 2 months ago

For now i believe we are going to leave this as-is. If someone wants to dive in and figure out how to move the state to the remote like we do with settings, a PR would be much welcome.

KaKi87 commented 2 months ago

There might be a clean way to do it

How about a plugin ?

code-asher commented 2 months ago

How about a plugin?

Maybe! Something similar to settings sync, where it syncs the state to and from the disk maybe?

KaKi87 commented 2 months ago

Yeah. Maybe more code-server features could be implemented as plugins and preinstalled for easy activation.

code-asher commented 2 months ago

I like that idea.

code-asher commented 1 month ago

Went ahead and re-opened, still no plans but I do think it would be nice especially since native settings sync does not work with code-server.

fulllagado1 commented 1 month ago

What is being willed is to visual code work as Jupyter Lab does with workspaces, totally portable. In Jupyter Lab, if I run a python file at home computer and open Jupyter interface on work computer, I get the same screen. If I do in code server, I get a new screen and if I need to rerun the python file (mainly if it is a server app), I need to open a new terminal (original one became a ghost, vanished) find its pid, kill it and run again. If I open a next server, it even vanishes from forwarded ports panel, inducing to open a new terminal, start next server again, with a new port (the previous one is used, by a ghost process). Jupyter Lab guys figured out those problems in the beginning of Jupyter notebook classic as reporting already running terminals and made somehow web development easier done in multiple machines than visual code server.

benz0li commented 1 month ago

@fulllagado1 For your use case, use a terminal multiplexer such as screen or tmux.

code-asher commented 1 month ago

Seems the upstream issue for this was closed right away but maybe with enough upvotes we can get it changed without having to patch it here: https://github.com/microsoft/vscode/issues/210775

KaKi87 commented 1 month ago

maybe with enough upvotes we can get it changed without having to patch it here

In a century, maybe.