Save UI state periodically to prevent loss on shutdown

[jankalfus]

• VSCode Version: 1.5.2
• OS Version: Windows 10

Steps to Reproduce:

1. Let VS Code open, lock the computer
2. Let Windows install updates and automatically restart the computer

After logging into Windows and launching VS Code, VS Code opens the project that was opened last time, but it doesn't restore editors to the state they were in last time. It restores some much older state instead (probably from last time the "Close folder" menu option was used). Very annoying.

[bpasero]

@jankalfus this indicates that Windows is not shutting down VS Code gracefully but rather terminates it. We would need to periodically save UI state to prevent that.

[jankalfus]

I have also noticed that when using F12 (Go to Definition), VS Code can be confused with certain files (probably those that weren't existing in the restored state, but were created later).

The issue is the following (BTW this relates to TypeScript .tsx and .ts files, I haven't tested any others):
When using F12 with a symbol, VS Code opens a new editor tab with an identical file opened and sets the cursor at the import, instead of going to the symbol import in the currenty opened editor tab. Expected behavior is to just set the cursor in the currently opened tab.

[YoshiWalsh]

I'm not sure that periodically saving the UI state is the only way to achieve this. With other Windows programs, they appear to be able to execute some code when the computer shuts down. For instance, Paint.NET will prompt you to save any unsaved changes, and will even halt the shutdown until you have given a response.

I'm having trouble finding up-to-date documentation about this, but it seems in Vista Windows was changed to allow programs 2 seconds to exit once a shutdown is initiated (https://blogs.msdn.microsoft.com/oldnewthing/20070416-00/?p=27243/), and I can't see any sign that this has been changed since. Would it be possible to use this time to store the UI state?

[petermilan]

+1

[youurayy]

Why periodically save and why try to save on shutdown?

The changes need to be saved as they happen, e.g. new window or tab open, moved or closed -- same thing that e.g. Chrome does with its internal DB.

[umdstu]

Yes, I understand that this is a free project, but this is a Microsoft product, build by and managed by mostly Microsoft employees. This means there is (mostly) a large corporation running the show (for the most part, yes it's technically open source). I encourage you to read the difference between vscode OSS and Microsoft Visual Studio Code the commercial version. I say all of this only because, although it's 'as is' software, there are certain expectations, warranted or not.

But @mar-ses points out the main problem- lack of feedback. "It will be done in 2021" is much better than silence.

Finally- my initial comment was meant to be overly antagonizing, and it's had the desired effect; to draw more attention and activity to the issue at hand :)

[adbakke]

I just wish this would at least be labeled as a bug, not a feature-request, it really is incorrect. I guess it's not a fun new feature and since it's in the feature request tag no one pays any attention to it.

Noting that comments on this case have taken a turn for the worse as far as tone goes.

[egamma]

We are currently working on the January iteration plan and this issue will be on it.

[umdstu]

That's awesome @egamma !! Sorry that I had to be an a-hole to get some eyes on this, but I guess it worked. There will be many grateful folks out there once this can be tackled.

Will it be addressed as a Feature Request or a Bug?

[Noiredd]

Noting that comments on this case have taken a turn for the worse as far as tone goes.

True, the community could have behaved more professionally about this. But on the other hand, I have some understanding for grief this problem had caused. A minor bug or lack of a desired feature can become annoying in the long run, but sudden losses of work are extremely frustrating immediately.

Fortunately, we'll soon be able to forget about this at all. Thank you team!!!

[akontsevich]

We are currently working on the January iteration plan and this issue will be on it.

Thanks much!

[bpasero]

Pushed a change (#87158) that will:

• save state every 60s
• save state when the window looses focus

The real fix is for Electron to provide API to detect the system shutdown case on Windows (e.g. what electron/electron#15620 suggests).

These changes will probably not help when VSCode has focus and windows restarts, though in my testing it works when any non-vscode UI is popping up (e.g. some prompt from Windows to apply updates). I think this is the best we can do for now.

[Noiredd]

Thank you!

The real fix is for (...)

(...) for VSCode to save state any time it changes: when opening and closing windows and tabs. This is the most robust solution.
@bpasero: detecting shutdown is brittle, would only fix half of the problem. Think of a power loss or a hard reset case - you can't "detect" those, so we would still lose state. Please, please keep this in mind if you ever come back to reworking this, because if you later change to relying on Electron, you'll revive this issue.

[bpasero]

This fix is a tradeoff between having to compute and save the UI state every time it changes (keep in mind: any cursor move is a change in UI state) and protecting against crashes. I many cases we are already storing the UI state when it changes but there are a few exceptions as the example above.

Btw: if Windows decides to just kill VSCode we are at the mercy of how robust SQLite is in those cases (the DB we use for all state). The DB only closes on a proper shutdown, but not on a crash or Windows restart. Having the Electron API might allow us to properly close the DB.

[akontsevich]

The real fix is for Electron to provide API to detect the system shutdown case on Windows

@bpasero Please remember: bug exists on all platforms: Linux and Mac as well, not only Windows.

Btw: if Windows decides to just kill VSCode we are at the mercy of how robust SQLite is in those cases (the DB we use for all state). The DB only closes on a proper shutdown, but not on a crash or Windows restart. Having the Electron API might allow us to properly close the DB.

Then close the DB after every writing.

[bpasero]

@akontsevich and my fix is for all platforms, not just windows.

Though from my testing I think I could never reproduce it on any platform but Windows.

Then close the DB after every writing.

Thanks for the suggestion, but I hope that is not needed, I trust SQLite to be robust specifically in this case because only 1 process is actually writing to the DB at all times.

[akontsevich]

@akontsevich and my fix is for all platforms, not just windows. Though from my testing I think I could never reproduce it on any platform but Windows.

On Linux happened many times for me as well in KDE on shutdown for example.

[Noiredd]

Though from my testing I think I could never reproduce it on any platform but Windows.

Here's how to reproduce on Linux. Do killall -9 code at step 5.

[bpasero]

@akontsevich you are right, I see it on Linux as well

[bpasero]

@Noiredd yes, I was referring to the state loss on restart while VSCode is running, not a forced kill of the application. I think killing VSCode like that or having a native crash is not the typical scenario we optimize for. The OS restart scenario is more typical to me and should now be fine (pending verification).

There are probably a lot more places in VSCode where a forced process termination leaves state behind. To give an example, all of the extensions are not receiving their deactivate() call which could mean that extension state is not persisted.

I still think that the powerMonitor API from Electron could further improve this, e.g. to gracefully shutdown extensions as well.

[wmertens]

Since the staye only changes when window layout etc changes, would it not be possible to persist as soon as it changed? Or can that not be detected?

…

[bpasero]

@wmertens most of the UI state is persisted when it actually changes but some is not. As I was mentioning earlier, editor state for example changes every time you move the cursor and is not very fine grained currently (it is the entire editor UI state for all editors persisted under 1 key). I can make another pass to see if the layout state can be persisted when it changes.