Vscode: 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.

[JoshuaWalsh]

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.

[bpasero]

From https://github.com/Microsoft/vscode/issues/62844: this also applies to UI state we accumulate on the main side such as the list of opened windows and window dimensions.

[Ruslan0Dev]

Where solution? My vscode restore older state instead (After every power failure or critical shutdown). Whereas sublimetext never failed. Please borrow fault tolerance from sublimetext. Thanks.

[Daijobou]

Today windows make a update and vscode again lost all actual files and show instead (tabs)files that long ago deleted or moved. So now I must search again ~50 files for my project i'm working with. :(

I would wish vscode not only store the actual files before restart windows, its prevent restart when files are not saved at all.

Offtopic: I hate windows 10 for his forced restarts. I never shutdown or restart my system. I use hibernate mode, because I have many tools and files open. I hope the next windows is more modern and will be more linux, so restarts are not required. Its feel like year 1995.

[youurayy]

Iit's possible to disable win10 auto restarts, google it.

But this buggy and very annoying behavior of VSCode could be perfectly
avoided by saving the window presence and position changes as they happen
in real-time, thus not having to worry about abrupt process kills.

On Thu, Dec 27, 2018, 12:15 Daijobou [e-mail] wrote:

Today windows make a update and vscode again lost all actual files and
show instead (tabs)files that long ago deleted or moved. So now I must
search again ~50 files for my project i'm working with. :(

I would wish vscode not only store the actual files before restart
windows, its prevent restart when files are not saved at all.

Offtopic: I hate windows 10 for his forced restarts. I never shutdown or
restart my system. I use hibernate mode, because I have many tools and
files open. I hope the next windows is more modern and will be more linux,
so restarts are not required. Its feel like year 1995.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/12058#issuecomment-450121972,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAj7Hfkf8PKsJ9uor7d9xTnVbTb24Ajtks5u9J3BgaJpZM4J9hZ6
.

[atiqorin]

Regarding closed: #65908. There is something else going on. I did update vscode yesterday. Had atleast 13 tabs pinned and open. 7-8 of them were opened automatically after I started my pc yesterday morning. So while going out of work, as usual I didn't close vscode and shut down my pc. I did restarted vscode two times yesterday. Once after the vscode update and once after I had a corruption on my yarn cache. Few files were probably not opened because before opening vscode, I stashed my changes, merge another branch. Maybe the files that were newly added on my branch were removed while checking out other branch caused the files to not auto open in vscode (Just speculating, I didn't even open vscode while doing the merge or stashing. Opened vscode after I checked out my branch and popping my stash. So the files were there at the time of vscode opening.). Now long story short, when I opened vscode today, just 3 files and an untitled tab were open. One I keep open all the time. Never had issue with that file. One other I am sure I opened yesterday by control clicking the interface usage. Another one was open for 3-4 days. However all the other opened tabs are closed, even the ones that opened yesterday automatically when I opened pc.

I don't know how to reproduce this. I believe this is related to this issue and creating another issue will just cause duplication, so commenting here. Thanks.

[youurayy]

tl;dr this thing is flat broken

On Wed, Jan 9, 2019, 16:17 Atiq Khan [e-mail] wrote:

Regarding closed: #65908
https://github.com/Microsoft/vscode/issues/65908. There is something
else going on. I did update vscode yesterday. Had atleast 13 tabs pinned
and open. 7-8 of them were opened automatically after I started my pc
yesterday morning. So while going out of work, as usual I didn't close
vscode and shut down my pc. I did restarted vscode two times yesterday.
Once after the vscode update and once after I had a corruption on my yarn
cache. Few files were probably not opened because before opening vscode, I
stashed my changes, merge another branch. Maybe the files that were newly
added on my branch were removed while checking out other branch caused the
files to not auto open in vscode (Just speculating, I didn't even open
vscode while doing the merge or stashing. Opened vscode after I checked out
my branch and popping my stash. So the files were there at the time of
vscode opening.). Now long story short, when I opened vscode today, just 3
files and an untitled tab were open. One I keep open all the time. Never
had issue with that file. One other I am sure I opened yesterday by control
clicking the interface usage. Another one was open for 3-4 days. However
all the other opened tabs are closed, even the ones that opened yesterday
automatically when I opened pc.

I don't know how to reproduce this. I believe this is related to this
issue and creating another issue will just cause duplication, so commenting
here. Thanks.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/Microsoft/vscode/issues/12058#issuecomment-452710878,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAj7HV8t-kFml53XbL-8aqbZeUN0JsGlks5vBfnngaJpZM4J9hZ6
.

[agilgur5]

I'm having this problem on my Mac too, whenever VSCode freezes up or I have to restart my computer, I re-open and I'm back to a state from a month ago :/ (and #66633 is the same problem on Linux)

I agree with @youurayy that this feature shouldn't rely on or require a graceful shutdown, one can't guarantee that will ever happen. Makes sense to save the state on-change to prevent this as other tools do

[Somebi]

Just save the state when closing and opening files and on interval basis, for example once per minute or every 5 minutes if no save was performed? Generate hash and compare, to avoid saving same state again and consume system resources.

[ddfridley]

I agree with Somebi's suggestion. I'll also add that my PC was in standby, when windows 10 did the update. I don't know if that effects what events VS code gets (if any). I'll also add that I wish the state information was stored in each folder that was open (I have 3 separate instances in their own folders open), and then when VS code starts up, it would open up 3 instances again. I understand this is not the most urgent features, and I really appreciate VS Code. Thank you for the work you do.

[Noiredd]

Any attention to this? It's been over 2 years since this was raised.

Below, alternative steps to reproduce the issue, independent of your OS:

1. Launch an existing session of Code, say there are files A and B open
2. Close tab B
3. Open an existing file C but don't make any modifications to it
4. Create a new tab (let's call it D) and write "foo" in it, without saving
5. Kill the code process (or hard-reset your machine)
6. Launch Code again

As a result, you will see tabs A, B and D open. B will be reopened, while C will be lost.
If you created a new window and only used it to view existing files (more of the C case), this will mean the loss of an entire window. If you had multiple windows and closed one of them before step 5, it will be revived.

[Yanpas]

Steps to Reproduce:

1. Open vscode
2. Open some files, wait some time
3. killall -9 code
4. Open vscode again, these files are not opened

I never close vscode on my work machine, sometimes power goes down, PC gets rebooted and I have to manually open each file that was opened after vscode launch. Chrome saves opened tab periodically, add this to vscode too.

[adbakke]

What's the lower-limit of comments on a bug before it gets addressed for this project?

🤔

[mar-ses]

Just commenting to also note that this is an issue on Ubuntu with shutdowns (see #36964), although I assume the proposed fix would work for all systems.

[ackvf]

74083

search keywords: tab groups lost after Windows crash BSOD session lost

[youurayy]

Could someone get this one moving?
@alexr00 @joaomoreno @Tyriar

One of the most popular editors (if not No.1), and not saving window state across process restarts, in 2019...

[Tyriar]

@youurayy please don't ping random people, we get way too many notifications already.

[youurayy]

@Tyriar sorry, I've tried to reach someone currently active on bug triage, as this one seems to be wrongly categorized as a feature-request when it's in fact a bug, as I think this is commonly expected behavior. (Or perhaps the README should say "Doesn't persist window state across restarts.")

[Meai1]

It's an issue every single day. It's the most visible, jarring problem that practically everyone is going to have. Just today I had yet more long deleted files show up in my workspace. They keep showing up, no matter how many times I remove them. The entire tab/open files experience is totally broken. For years(!).

[Glamurio]

Just today I was wondering if anyone else has been running into this issue, and it turns out I'm not alone. Pretty please get this fixed, it shouldn't be a surprise that this is really irritating when working with VSC.

[adbakke]

Can anyone explain why this is tagged as a feature-request and not a bug? If the behavior of a normal shutdown is to save workbench state and reopen in that state later, why would shut down occurring through the operating system not be exactly the same? If it should be then this would be a bug, not a feature request.

I am open to understanding why it is a feature request and not a bug.

[felixpenrose]

+1 this is very jarring - a saved editor state is the easiest way to continue what I was working on the previous day. Just switched from sublime and this is so far the most annoying issue in VSC

[VigiFyre]

Title and tag changes make me worry that the issue might have been misunderstood.

It's not that VSC doesn't keep backups for cases like sudden power loss (by the way, it absolutely should). It's that VSC doesn't save the session even when Windows is shut down gracefully. When Windows is shutting down, apps are even able to ask Windows to wait up until app was able to save everything, so i'm pretty sure that Windows doesn't just kill apps when it's shutting down or restarting. And it doesn't happen only when Windows decides to update, for example – it happens every time PC is shut down for the night.

It's not a feature request, it's a bug.

Using VSC to work feels a little bit like walking on a minefield:
Forgot to manually open VSC from task bar before double-clicking any text file? Whoops, your entire session is rewritten.
Forgot to manually close VSC before shutting down the PC? Whoops, your session is gone again.

[akontsevich]

It's not that VSC doesn't keep backups for cases like sudden power loss (by the way, it absolutely should). It's that VSC doesn't save the session even when Windows is shut down gracefully.

It happen not only in Windows, but in Linux too.

[RafaelQuirino]

I saw that people (and even the title of the issue) are suggesting that it is necessary to periodically save the state of the app. But couldn't we just save the state of open files and folders each time a file or folder is opened ?

[youurayy]

@RafaelQuirino no I think the consensus here is to save-on-change (i.e. https://github.com/microsoft/vscode/issues/12058#issuecomment-412556800). But you are right, the issue title should be adapted accordingly.

[zhuhang-jasper]

My issue #80760 is closed but I have to point out maybe it shouldn't?

I'm suggesting auto-save the workspace file. Just like how you do File > Save workspace as....
Which will keep track of the active files/tabs opened in editor.

Right now, the workspace will only be saved upon exit app properly.

[petermilan]

Really an annoying bug in an IDE

[umdstu]

How is this still open after 3 years? Is it on a roadmap somewhere Microsoft folks?

[wnsnty]

This issue has been referenced more than 20 times and has been continually commented on over the past 3 years. At what point does an issue get reevaluated? Because the tags on this one are wrong.

In what world is "UI state is lost after program exited abruptly" considered "working as intended"?

[RafaelQuirino]

I opened an issue that was closed as a duplicate of this one. I noticed that this one, despite being kinda old, had a lot of activity recently. A lot of people is annoyed by this. Are you planning to solve it or not ? Because it is very serious to me, to the point i have to abandon the application. Someone on the team, please, solve this problem, or, at least, say if you're going to solve it, and give some date. I don't know how much you value individual users, but i'm not using the app until this get solved.

[wmertens]

Curious, I use VSCode on macOS and I never noticed this problem, and I've had my fair share of crashes. Is it limited to Windows? What is the cause?

[akontsevich]

@wmertens no, as You can see above it happens in Linux as well.

[wmertens]

@akontsevich I wonder what macOS is doing differently, or maybe I was lucky enough not to encounter it? Is there a way to reproduce it 100%? Maybe some editor setup steps followed by a kill -9?

[petermilan]

Yeah happens on linux as well (In my case it is Kubuntu). It is really annoying to see same opened files every single morning. And trying to recall what files were opened the day before.

[petermilan]

I am seriously thinking about a workarround: making custom command for shutdown of VS code like:

#!/bin/sh

$(kill $(ps -ef |grep `whoami`| grep -m1 "/usr/share/code/code --unity-launch" | cut -c10-15))

The command above will stop VS code and remember last state of it.
The grep search in process /usr/share/code/code --unity-launch can be different on different systems.

Wondering if I could call it with shutdown -h now and use it as custom shutdown script,
But will need some time to test or tune it, or even perhaps somehow call as a script before regular shutdown of OS.

[wmertens]

How is that different from shutdown? All processes get a SIGTERM.

[felixpenrose]

How many years does this bug have to exist before it gets addressed? (and yes, it's a bug, not a feature-request). Every morning I start up my PC, yet again the sessions starts in a random saved state from days ago, most of the time it's not even the same work space, meaning I've lost my checkpoint from the previous day. Right now the "saved" session state is an entirely useless feature, it'd be less annoying if it just didn't exist, rather than this constant reminder that it doesn't work correctly.

The only time the save session state works is if I manually close VCS and re-open it, which is just something I don't do. I open it when I start work, then I shut my PC off at the end of the day. I'll have a multitude of windows open, so I don't manually close everything and I shouldn't need to either.

[wmertens]

I'll add that I was able to reproduce this on macOS: when my system crashes or when vscode is force-killed, it restores the previous state, not the latest state.

[youurayy]

Let me add something to this -- even with a File->Exit (or Cmd+Q) exit, the latest VSCode is not remembering the width of the Side Bar per window.

The whole UI state should be saved. Per window. After any kind of exit/crash.

[Noiredd]

It's been 3 years since you were first alarmed of this problem. Nothing has been done to fix it, we still keep losing our sessions, and this is still marked as feature-request? You could at least admit that it's a bug...

[youurayy]

Imagine opening 3 or 4 new windows, searching for info and opening all the files you need for your task, carefully aligning ale the open editor tabs to compare data and configs.

Then your laptop crashes in sleep.

You reopen all apps and they restore their UI state without any issues.

You reopen the VSCode and you are back at zero. You have to repeat all your work from the day before, because some people here think that this is an addition feature, and not the most serious bug of the product.

@satyanadella help !

[chiboreache]

This is really annoying as fhell !

[umdstu]

I'm not sure why people are still complaining about this. It's clear the current team is incapable of this level of development, it's just too difficult for them. Otherwise it would have been done by now. We'll have to wait until they hire, or someone volunteers, one that is competent enough to resolve this aggravating issue. Just don't hold your breath, it may be another 3 years or they're just waiting for Microsoft's future replacement to vscode.

Let's just be glad our browsers have restore tab functionality.

[youurayy]

The saving of the layout currently does happen when the editor is quit through File->Exit.
The cheapest way would be to add a 1 minute timer that would be calling this same layout-saving code.
Ideally this would be done by someone familiar with the codebase enough to know if that can collide with extensions, etc.
But in principle it should be really easy.
The problem is that this Issue is buried under tons and tons of other issues. And I'm afraid the PR, if submitted by one of us outsiders, might just get buried under other PR's too.

[wmertens]

@umdstu I don't understand how you can complain like that about free software. If it is really so easy to fix for competent programmers, please make the fix, since you're commenting from the viewpoint of a competent programmer.

There is nothing to be gained from commenting in this manner, all you're doing is adding negativity, making sure that this issue is sorted lower on the list.

@youurayy I think a problem is that you can't prevent Electron from being killed until it saved the state. Perhaps the state should be auto-saved every time it changes; not sure why this is not already the case.

[umdstu]

@wmertens without complaints 'like that', nothing may ever happen. Maybe you're content having this bug for 3 years, I'm not. I also never said it was easy, nor did I say I was competent enough to fix it. If I was, I would have. Therefore it only stands to reason that they dont have those people. That's just logic. Don't presume that I was commenting from any viewpoint other than the statement made.

[umdstu]

Also for what it's worth, I highly doubt my 'negativity' is going to make this any lower on the proverbial list than it already is. It's a nice sentiment though.

[akontsevich]

The saving of the layout currently does happen when the editor is quit through File->Exit.
The cheapest way would be to add a 1 minute timer that would be calling this same layout-saving code.

Problem could be deeper: seems problem happen not because VS Code does not save the state, but it loses, cleans up or even corrupts the state for some reason. So think only project programmers can fix.

[chiboreache]

Just making Exit available for binding - would be nice workaround, since Super+Q does not work

[mar-ses]

Just to add my two cents on this: I agree partly with @wmertens; this is a free project, it isn't fair to complain that someone else isn't doing the work necessary to fix an issue. We should appreciate all the work that already went into making it. The fact that all of us are clamouring for a solution within VSCode, rather than jumping ship to another editor, is proof that people do appreciate VSCode.

However, I think one of the reasons people are complaining isn't the fact that it's not being fixed, but that they feel it's being swept under the rug. It doesn't seem to feature as a problem that the developers find important, it's not in any iteration plans, and it's just being ignored. It's still marked as a feature-request.

In that case, I think it makes sense for users to draw attention to it, and to let the developers know that this bug is a problem that impacts the usability of VSCode. The fact that there are 55 comments in this thread should be proof that lots of people find this bug annoying.

[felixpenrose]

Agreed. Some acknowledgement from a relevant party that this is a bug and will have some eyes look at it in a reasonable time frame would be great.

It's a bug I regularly encounter, not a once in a while problem.

[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 (https://github.com/microsoft/vscode/pull/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 https://github.com/electron/electron/pull/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.