search

microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.66k stars 28.68k forks source link

Reset VS Code after extended time of nonuse #132167

Closed digitarald closed 8 months ago

digitarald commented 3 years ago

What if: Many users that open VS Code after many years of not using it could have a better experience when they started with a fresh install.

The reasons for bad experience amplify each other, and we can't expect that a user re-evaluates each of these when re-opening an old install:

We saw this frequently in usertesting: A participant who self-reported as not using VS Code downloads the most recent version and after launch, defaults to the last opened workspace. There is usually have little or no recollection of the project they are looking at. Even worse, VS Code is set up in unexpected ways, binary paths changed, and some of the extensions are legacy or deprecated.

We expect this to be common, as it is easy to download and install VS Code just to try it out. It takes little space, so keeping it around afterwards doesn't hurt.

What could reset mean:

  1. Don't restore the last-opened folder, as it provides little context.
  2. Sticky prompt to restart after downloading critical updates for VS Code and extensions
  3. Offer to reset VS Code's user-data
  4. Something else?

Related, Firefox does something similar for similar reasons (old extensions, performance issues, etc).

isidorn commented 3 years ago

I think blowing up the user data dir would would do most of the things we want (1 and 3)

Regarding 2. there are always some critical security updates. And it can as well happen that the next monthly release has some security fix even if the user updates regularly. So I would think about this problem unrelated to the long period of inactivity.

@bpasero what do you think about user data blowup after some period of inactivity?

bpasero commented 3 years ago

Related to / duplicate of:

We cannot "blow up user data dir" because it may contain backups of unsaved changes.

isidorn commented 3 years ago

@bpasero I think we can blow up user data dir because:

  1. We would first ask the user to confirm
  2. We would only ask the user after an extended period of time of inactivity (thus reducing chances that something useful in is in the hot exit state)
  3. This is similar to how we ask users are they sure they want to close vscode when they have unsaved files (hot exit disabled)

So we should just make sure that the dialog when we ask the user makes it clear that unsaved changes in files will be lost.

bpasero commented 3 years ago

I am not entirely sure we can technically delete the user data dir via a restart of the app, because we would basically have to delete it on startup before the ready event. @deepak1556 can maybe chime in if it is save to do so.

To be honest, I have not heard of an application that would behave like this, so I am not sure this makes sense. What is the motivation?

isidorn commented 3 years ago

@bpasero Firefox does this. And I actually got that dialog - it gave me a feeling of being offered to cleanse my previous sins and start fresh.

Motivation: user tried out vscode couple of years ago and left it in a bad state (broken settings.json, hid the activity bar and has no clue how to bring it back...). In a user study it happened that a user had created a chrome launch configuration in his user settings, and now he was trying to setup PHP debug which was impossible due to his old user configuration which is shared across workspaces and does not allow our "let us help you start debugging" experience.

I think we will see more and more users coming back to VS Code after some time as they give us a 2nd chance.

Though let's first see if it is possible at all from @deepak1556

isidorn commented 3 years ago

Downside of this is that it would be another dialog. Since I hate dialogs in general, I am not 100% convinced we need this.

deepak1556 commented 3 years ago

User data dir not only contains vscode application data but also lot of configurations for the runtime which get processed before the ready event. So I would strongly advice against nuking the directory while the application runs, the application is always free to touch files that it owns inside that directory, so maybe focus on deleting only those data ? But if you really want to start fresh, then try this flow

1) Confirm with user about starting with fresh state 2) Launch the app and set a new user data path via app.setPath https://github.com/electron/electron/blob/main/docs/api/app.md#appsetpathname-path 3) Delete the old directory in any of the successive runs

bpasero commented 3 years ago

Yeah we do have situations where we change the user data dir dynamically even after starting but before ready event. Mainly to support the portable mode:

https://github.com/microsoft/vscode/blob/9520f0a515e7e24802c92f885a0efb242fca3831/src/vs/platform/environment/node/userDataPath.js#L49-L49

digitarald commented 3 years ago

To simplify, we could break down this work into 1. Don't restore the last-opened folder. (reasonably uncontroversial) and 3. Offer to reset VS Code's user-data (will require some tweaking and experimentation) entry.

digitarald commented 8 months ago

Duplicate of https://github.com/microsoft/vscode/issues/130510