Terminal: Please provide a way to delay updates

[hyphenistic]

Description of the new feature/enhancement

I keep Windows Terminal open all the time. I also check for Microsoft Store updates daily. When an update to Windows Terminal is installed, it kills dozens of tabs I have open.

Proposed technical implementation details (optional)

It would be better for me to know that an update has been downloaded and is pending to be installed. I could then close all instances of Windows Terminal myself and when opening it the next time it would update before running. This is how Google Chrome works.

[WSLUser]

It would be better for me to know that an update has been downloaded and is pending to be installed.

Terminal has no control over that. That is entirely dependent on how your settings are configured for the Store.

[hyphenistic]

Fair enough. I had not looked into Store settings before. I always
clicked on Get Updates and it would download and install updates. I've
turned off the auto-updates setting and will see how it behaves. If it
checks for updates but does not install until I say so then this will
work. Thanks.

[DHowett]

So, I asked the application packaging and deployment team about this. Their answer was fairly direct: when you click _get updates_, you’re considered a “seeker”. People who actively seek updates get a different behavior than people who let the passive auto-updater update apps for them. Seekers’ applications are forcibly terminated, because they told the OS “no, give me updates, right now.”

[hyphenistic]

Bummer. I don't suppose there's a way for Microsoft Store to simply show
me if updates are available then? I'm also thinking along the lines of
Windows Updates. I can check for updates and install them but the restart
doesn't happen without my permission.

[electronic-dk]

Probably something along the lines of how Edge, for example, handles the updates would be cool i.e. show that there's a new version available but not force restart the app right away. I understand that that's probably not the easiest issue to solve and there's probably no single solution that would satisfy everyone but maybe that's something the MS store could move to in the future.
That would probably be somewhat solved with the winget once it learns how to show the apps/packages that are ready to be updated.

[factormystic]

So, I asked the application packaging and deployment team about this. Their answer was fairly direct: when you click _get updates_, you’re considered a “seeker”. People who actively seek updates get a different behavior than people who let the passive auto-updater update apps for them. Seekers’ applications are forcibly terminated, because they told the OS “no, give me updates, right now.”

Thanks for checking into this @DHowett and so if there's nothing that the Terminal team can do about this I guess that's that.

HOWEVER:

This response from them is _ultra lame_. Yeah, I'm clicking around to see what's up, or maybe because I want to see what's updated, or maybe because I know some other app got updated.

But what I'm saying with those clicks isn't "please kill my terminal instances, which close/secretly detach my various terminal panes, and the web server(s), logs tails, etc running inside of them, thus essentially resetting my active development environment from some other app, on some other virtual desktop".

To hear me say this and think "yeah, that's certainly what the user intended when they were clicking around the store app" is foolishness. Whoever is holding on to this foolishness on the store team needs to have their thinking updated.

What can we do to get this scenario into the store team mindset? Is there someone from that team we can get onto this thread? Is there someone we should complain to? Can you take this feedback and send it back to them?

---

Another lens here is, what will it take to make this into a pleasant experience instead of a disappointing experience? Certainly getting the store team to up their game would be nice, but if that's not going to happen then I wonder what else can be done.

For example, hypothetically, could each terminal instance record it's current pane layout, detach from running processes that it started, allow the store to kill it & bring it back (somehow), detect that this is what happened, restore its pane layout, then reattach each child process?

The thinking here is that the store can kill the app, but the damage is now avoided because everything is restored.

[WSLUser]

Feedback Hub is the official way to communicate concerns about the Store to the Store team. I would say it's likely to be ignored but with the Store now being the only way to purchase products directly from MS, theres a higher than normal chance this feedback will get attention but not necessarily resolution.

[qm2k]

My issue was marked as duplicate so I will repeat my suggestion here: update the app, but keep the state. It would be really cool and different. At least on my system the subprocesses are not really getting killed, so I believe it must be technically possible to attach them back (e.g. add some intermediate process controlled through a pipe that survives).

And yes, I totally agree with @factormystic about the response that users somehow want this behaviour: it is superb lame and arrogant to claim this. It's worse than the Clippy was. In no system ever was my command-line session was terminated because the terminal package needed an update. Sooner or later it will happen while someone updates a mission-ciritical system remotely without tmux, or do a multi-month calculation or rendering, or mine/save bitcoins, and it will all be in the news.

[huoyaoyuan]

People who actively seek updates get a different behavior than people who let the passive auto-updater update apps for them.

@DHowett I have to point out that the passive auto-update is still too aggressive for Terminal.
Yesterday night I left a long running task (~10h) in Terminal, and find it auto updated in about 5h. I'm not so angry because there are save points, but the update staggery is definitely unsuitable.

[DHowett]

Fair.

Given that we can’t change the store’s behavior, your best option is to extract the msixbundle like a ZIP file and run WindowsTerminal from inside it. It will never update, never change, never get terminated by the store, not be codesigned, not be trusted by your organization, and is completely unsupported but _it works._

[jsejcksn]

FWIW, I recently saw that the store version of Terminal has implemented a modal confirmation dialog before being closed by the store. No screenshot to post. Maybe someone else can link to an update about the new behavior.

[DHowett]

Unfortunately, the store simply terminates Terminal even if we sink the close message. We’ve tried. 😄

[brobichaud]

Simply blaming this on the store isn't really productive. Pointing out it's a limitation of store apps sure, but perhaps the line of thought needs to move towards options, such as:

1. Should terminal NOT be a store app?
2. Should terminal fully persist its state?

The second option seems ideal to me. A bunch of work for sure but could solidly address the issue. If it persisted state such that when terminal is restarted after an update it brings you back to exactly where you were with all command history, scroll position and all those other little nuances retained. The one thing it probably can't fix is if a tab was in the middle of some long running operation, not sure how to address that.

The current behavior is quite infuriating and makes me not want to use terminal. It's almost as bad as Windows updates auto-magically losing all context of everything I had open.

[mg-christian-axelsson]

1. Should terminal NOT be a store app?

I think providing a proper out of store option is a reasonable request.

1. Should terminal fully persist its state?

The second option seems ideal to me. A bunch of work for sure but could solidly address the issue. If it persisted state such that when terminal is restarted after an update it brings you back to exactly where you were with all command history, scroll position and all those other little nuances retained. The one thing it probably can't fix is if a tab was in the middle of some long running operation, not sure how to address that.

Trying to persist state is pretty much impossible for any reasonable complex setup, even if you disregard running processes. Attempts to do so just rubs it in even harder in my experience (like the Windows Update automatic reboot starting up programs again but the state within the program is completely lost)

[zadjii-msft]

Hey for the record, there's a bunch more discussion about restoring terminal state in #961, so maybe we should move the discussion there.

[ckovey]

Restoring state would be cool, but one other issue I believe for this thread are processes that listen/don't terminate when updates happen and Terminal itself gets closed

For example a Laravel app I am working on. I will have 2 tabs in Terminal, one for running commands like git or scaffolding, and another that is split into 3 panes to: 1) run the local dev server php artisan serve, 2) run webpack and compile Sass, and 3) one to compile TypeScript

These 3 are running until I ctrl-c them, listening for web requests or watching file changes to automatically compile assets for web.

When an update happens like yesterday for 1.3.2651.0 my Terminal window goes away but all of those processes are still running and the only way to stop them is killing via task manager. At which point something like #961 would be nice to restart the 3 :)

All of my tabs/panes are running WSL Ubuntu 18.04

[brobichaud]

1. Should terminal NOT be a store app?

I think providing a proper out of store option is a reasonable request.

It definitely feels like an easier option than restoring state. Would it be possible to continue offering terminal as a store app but have a side channel that offers it as a simple download for those that want to control the update process?

[zadjii-msft]

have a side channel that offers it as a simple download for those that want to control the update process?

Maybe something like winget?

[dlong500]

1. Should terminal NOT be a store app?

I think providing a proper out of store option is a reasonable request.

It definitely feels like an easier option than restoring state. Would it be possible to continue offering terminal as a store app but have a side channel that offers it as a simple download for those that want to control the update process?

I've never been keen on using the store for a variety of reasons, and this type of situation just confirms my frame of mind. Auto-terminating without at least having to confirm the shutdown (with an option to cancel the update) is just crazy. It seems completely reasonable to offer a more admin/developer friendly option for installation via something like winget where you can still check for updates without having to close all terminal windows before checking out of fear everything will get shut down.

It's just completely unintuitive behavior the way it is right now. We should be able to check for updates manually or automatically (with notifications) but still get to decide when the update actually occurs. And we should be able to do this in an officially supported way. Sorry to sound demanding, and I understand that the terminal team isn't in control of the current behavior (due to the deployment via the store), but not terminating an app when an update is published has been standard practice for developers for a long time.