Store state on remote instead of browser

[abhay-ranawat]

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

• Web Browser: Chrome v91
• Local OS: Windows 10
• Remote OS: Ubuntu 20.04
• Remote Architecture: Debian
• code-server --version: 3.12.0

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 : #4185

[jsjoeio]

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

[benz0li]

I have the same issue.

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

[jsjoeio]

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]

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]

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]

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]

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]

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.