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.

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.

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 all,

After a long series of mails with the Store team, we've managed to get some updates to this experience. They should be rolling out in Windows 11 Insider Preview Build 25131

Improved app updates: We improved updates when clicking Update buttons in the Microsoft Store. We’ll skip over apps that you have open, so you don’t lose any important work. You can manually update the apps later.

This change isn't exclusive to the Terminal, it should be a better experience for all apps now. There are likely more improvements planned in the future in this space, but this initial update should greatly improve the experience. Thanks everyone for their patience here!

[vbrozik]

@zadjii-msft Great, thank you a lot! Is the app update improvement going to be backported to Windows 10? I think many enterprises will be using Windows 10 for a long time.

[zadjii-msft]

Is the app update improvement going to be backported to Windows 10

I honestly can't comment on the Store's plans because I simply don't know them. From prior experience, I would guess that this isn't something that'd come back to Windows 10, but don't take that as a definitive statement of any sort. I believe this is tied to a variety of changes to the platform code, so I don't think it's as trivial as pushing a Store UI update downlevel. (Again, speaking from hearsay and not expertise in how the Store works)

[zadjii-msft]

Sorry to necro this thread folks. Ultimately, the aforementioned fix didn't end up shipping outside of Insiders, because it had ~ u n i n t e n d e d ~ side effects. That's okay! That's the point of Insiders, to help iterate on designs.

Instead, a different path was pursued in the platform. I believe it was shipped in the Insiders SDK today, but I haven't confirmed which build exactly. Basically, we'll need to add a new property to our manifest to let the Store know "please don't force-kill me for updates".

I'm reopening this thread for now. When the next official SDK version is out, we'll need to add a new uap16 property to our manifest, and that should fix this issue for users on the latest Windows 11 bits.

It's not the most ideal solution in the world, but I'm happy to have any solution at this point.

The large volume of community feedback was really helpful in getting this prioritized with the rest of the teams involved here, so for that - I thank all of you ☺️

[mikehearn]

@zadjii-msft For those of us who would like to adopt the same fix in other apps, could you let us know what this uwp16 property is going to be? Unfortunately AppxManifest.xml changes aren't centrally logged or announced anywhere so the only other alternative is to poll the docs looking for new uap16 namespace items.

[zadjii-msft]

Would you mind if I wait till it's out of the Preview SDK? As we've seen in the past (literally in this thread), preview features sometimes have to be backed out before release, and I don't want to promise something to 3p devs that might not land. I'd be less reluctant if it was some preview feature our team owned, but I'd rather err on the side of caution with another team's stuff.

I'm setting up some time (soon^TM, I'll be OOF for June) to test this out in the Terminal with the Preview SDK and the folks who wrote the API - when I do, I'll surely link the dev branch here if you're really curious

[mikehearn]

@zadjii-msft Of course, that's perfectly understandable. I mostly just didn't want to forget this thread :-)

[zadjii-msft]

Spoke more with that team yesterday. They said it's cool to share.

<Package
  ...
  xmlns:uap17="http://schemas.microsoft.com/appx/manifest/uap/windows10/17"
  IgnorableNamespaces="uap uap17 uap16 mp">

  <Properties>
    <uap17:UpdateWhileInUse>defer</uap17:UpdateWhileInUse>
  </Properties>
  
</Package>

That property should be in the current Insiders preview SDK. For reasons we (the Terminal) can't use that till it gets released as part of the stable SDK, later this year.

[mikehearn]

Thanks man! When you say "insiders preview SDK", I'm not quite sure what that means. I know what Windows Insiders is (a preview build you can opt in to), but don't understand the relation between the SDK and Windows here. My company makes a tool that builds MSIX files and AppxManifests itself, without using any MS tooling. We can start emitting this XML tomorrow, no problem, and maybe we should. The real question is when Windows itself will start to recognize it.

[zadjii-msft]

Ah, by "Insiders Preview SDK", I mean this: https://www.microsoft.com/en-us/software-download/windowsinsiderpreviewSDK

Appxmanifest entries are a little weird sometimes. The tooling needs to be updated to know about this new manifest entry, separately from the OS actually supporting the feature. So the tooling will reject this flag if you try to build it using an SDK version before at least 25362. That's half the picture. The other half is the OS itself needs to recognize this flag, which again I think is only in builds >=25362. The Insiders -> Stable build numbers are a little weird these days, so I don't know what OS version that will ultimately become when it's officially released in fall. 22000.something, probably.

If you're building msix's without the official tooling, then I dunno how your tooling will react to "unrecognized" properties. I know the version from the SDK will explicitly reject things it doesn't know about, hence why we can't just add it to the Terminal today 😕

[mikehearn]

Got it, thanks. Conveyor (see https://hydraulic.dev/) uses the official AppxManifest XSD schemas to validate, so I guess we'd need to patch those schemas or wait until a new set is released. It probably makes sense to start using it immediately, as people don't rebuild their apps instantly.

BTW, do you know why it's optional? What's the scenario that breaks if everyone is opted into this? I'm head scratching trying to think of when you'd want the store to kill the app whilst it's in use, and I can't come up with one but clearly something went wrong with the first attempt and there's a reason it's now optional. I worry if we opt in our users automatically, we'll hit the same issue.

[mikehearn]

@zadjii-msft Looks like we're nearly there. I'm trying to work out what versions of Windows 11 support UAP17 and not having much luck. The PR says it shipped in the September 2023 "OS release". As far as I can tell UAP17 (and therefore this fix) requires build >=25936, but the latest version of Win11 available is 22631.2715

So is this still stuck in insiders/preview mode?