Proposal: Minimized UWP apps using the confirmAppClose capability should be activated when the user attempts to close them

[Felix-Dev]

Proposal: Minimized UWP apps using the confirmAppClose capability should be activated when the user attempts to close them

Summary

Today, when the user user attempts to close a minimized UWP app via the Windows Shell (Taskbar, Timeline,...) which uses the confirmAppClose app capability, they won't get notified by Windows in any way if additional input is required from them to properly proceed with the close request. Instead, the user will only notice that the app is not being closed, causing confusion to them as to why their close request is not actually closing the app. In fact, if further input is required from the user, they will only notice this once they themself brought the app to the foreground again.

This behavior is described in the docs here and the following GIF illustrates this issue using the UWP App Quick Pad (Github repository here) which is a modern text editor alternative to the classic Notepad:

Rationale

Win32 apps like Notepad show a dialog upon closing the app if additional user input is required:

While this example implementation is an improvement over the current situation for UWP apps it is still not perfect! For example, some time might have passed since the user last edited the file/data and thus they don't remember any longer if the data in question is something they need to save or not. As such, it would be quite helpful to the user if the entire app window is activated so they can quickly check the data referred to and can then decide if they want to save their edits or not. In other words, if the user attempts to close an UWP app like Quick Pad via the Windows Shell as shown in our example above, they would be greeted with the following screen in return if additional user input is required:

Closing the app via the Windows Shell is a deliberate action done by the user and as such should allow the app to be activated as a response if further user input is needed to proceed with the close request.

Scope

Capability	Priority
This proposal will enable end users to close a UWP app via the Windows Shell (Taskbar, Timeline,...) and be brought back into the app context automatically if further input from them is required to proceed with their close request.	Must
It is up to the developer to decide if the app needs to be activated and if yes, what content should be shown.	Must

Additional Context

@BenJKuhn Feedback Hub entry here.

[shaheedmalik]

So, it should notify like Win32 programs do in the taskbar.

[zhuxb711]

Agree

[BenJKuhn]

Felix, a little digging around shows that you're not the first person to try to use CloseReusted in this way. The documentation clearly states that the event doesn't fire when the app is minimized. While the documentation about the behavior is clear, it still leaves the question of how to properly implement this type of behavior, or whether it's possible at all.

I've reached out to a few people internally for their thoughts, and will let you know what I hear back. I'll triage the feedback entry once I get a bit more information.

[Felix-Dev]

@shaheedmalik I thought about flashing in the taskbar which I assume you mean (see image below) ()

Two things to note here: 1) Win32 Notepad does not flash its taskbar app button when attempting to close it while there is unsaved work. 2) As closing the app as described above is a deliberate user action I would prefer the app to be activated if further input is required from me. That way, the user can immediately see what further action is required from them. On the other hand, taskbar app button flashing would require another click until the user sees why their close request cannot yet proceed.

Also worth considering: Currently, there is no taskbar app button flashing support for UWP apps, even if you use a helper Win32 process. I'm not sure if (and tbh I don't think) MS has any plans to reintroduce this method of attracting user attention considering all the other Shell notification options available (tiles, badges, notifications).

[Felix-Dev]

@BenJKuhn @jesbis Would it help in tracking this issue if I move it to Project Reunion?

[shaheedmalik]

@shaheedmalik I thought about flashing in the taskbar which I assume you mean (see image below) ()

Two things to note here:

1. Win32 Notepad does not flash its taskbar app button when attempting to close it while there is unsaved work.

You're right. I am surprised at that. It seems like use cases such as that would be a common sense reason to use it.

[BenJKuhn]

There was some good discussion about this. Generally speaking apps should be saving state that they need to during suspend, and the close event was designed for a fairly narrow use case. Not waking the app is a key component. Once suspend fires, the system assumes it can close the app without requiring the resources or time needed to wake the app again. What's being requested breaks that model. The current behavior also requires that the window be visible, though I don't know whether that's incidental or inherent to the design.

It's clear that this has broad appeal as a use case for this feature. We've taken the feedback and the owning team will consider how to address this going forward. I'll defer to @jonwis as to whether he feel this fits better under the reunion charter.

[jonwis]

Since this is more about platform functionality please do transfer it to https://github.com/microsoft/ProjectReunion/issues and we'll track it there. I agree with @BenJKuhn , however, in that UWPs should save-suspend-terminate when prompted to do so. Maybe there's something Project Reunion could do to help simplify save-and-restore-state behavior while we think about how to expand the windowing & lifecycle models.

[Gavin-Williams]

@BenJKuhn So perhaps close should just close the app without regard to the ConfirmAppClose capability when the app is minimized, instead of not doing what the user has just requested. It is then the prerogative of the developer to correctly implement autosave if that's what they want.

I think it's also relevant that users don't consider minimized as meaning saved or even asleep. Minimized means .. minimized in visibility only. If I close a minimized app I want it to close, I don't want it to maximize. I accept that I will lose any unsaved work unless it's ToDo or OneNote because I know they autosave.

[BenJKuhn]

The example in the issue is the saving of local data, which seems straightforward. A big text string doesn't seem hard to figure out. There are other examples where apps may need to release or commit remote data in a way that has implications. For critical workflows, say a nurse entering patient information into a database and forgetting to save, a check on exit could be a process safety improvement, rather than just data loss as a concern. Quietly leaving that data in an app-local cache without committing it could lead to patient harm.

There are situations where the app will be closed by the system (e.g. an overnight update) and the user can't respond. Those situations will need to be handled gracefully by the app. In the example above, the app might leave a breadcrumb of some sort (e.g. an email reminder) on close to indicate that there's unsaved work.

For cases where the user is sending the signal that they're walking away (closing app, logging out), there are plenty of good reasons for an app to indicate "are you sure?". Perhaps the system could handle this better by letting the app inform the system that it's in an uncommitted / inappropriate state to shutdown during it's suspend handler, so that the user can be informed quickly without waking the app if they try to close later. The process could even be non-disruptive. E.g. a notification and deferred exit. Clicking the notification restores the app, ignoring the notification lets the system terminate the app in 10 seconds or so.

That approach would also enable the system to consider app state in resource policy decisions, which may be appropriate in some situations.

[stevewri]

This looks ready to move to the backlog for potential future feature work.

[SetTrend]

I'd like to add my two cents:

For document centric applications it's important to give visual feedback to the user about pending "unsaved" documents when she closes the application, even in minimized state.

Although it's suggested that apps should intrinsically save any unsaved work to temporary files from within EnteredBackground, it feels kind of disquieting, uncertain, dubious when the user isn't able to explicitly decide which documents to discard and which to persist when she deliberately closes the app.

I propose to take all necessary steps to bring the app into a state where LeavingBackground is called, if necessary, when the user deliberately closes the app.

The same should be true when a Windows user session log-off, shut-down or similar event occurs.

Perhaps an app may register its Dirty state to WinRT, so WinRT will be able to re-activate all dirty apps having confirmAppClose capability set.

[andriysavin]

@SetTrend I can't agree. Blocking PC restart or user log off with a modal dialog asking if the app should save changes (if this is something what you mean by visual feedback) is one of the most horrible experiences. And often user mechanically clicks the button allowing forced restart and looses all changes. The same can happen when PC is sent to sleep, and then a power outage happens, again, loosing unsaved changes. Apps should keep pending changes automatically, as you mentioned.

[VagueGit]

We write business apps and user-experience while important, is secondary to business requirements. Business requirements often specify to prompt the user to save before closing.

This is a business requirement that devs don't have a say in. It's one of the (many) issues that have stood in the way of UWP adoption for business apps.

Having said that, devs shouldn't be required to hook into this capability if they don't need to.

[SetTrend]

@andriysavin:

I see your point. Yet, let me share my point of experience with UWP apps:

Actually, it is a common user expectation to be warned about unsaved documents when closing an app or ending a user session. (Professional) Windows desktop apps all behave like this.

I've been part of a number of large development and office teams. At every desk I visited, when it comes to either restarting Windows due to Windows updates or when it comes to shutting down the machine, MS Excel or MS Word popped up, telling the user that unsaved documents existed. The users then either discarded some open documents/work sheets or continued their work before going home, thereby cancelling the shut-down process. They just had forgotten about the documents they opened throughout the day. And they felt safe about these office applications reminding them.

It wouldn't cross any of these users' minds to use an UWP app for their daily business.

I myself, for instance: The only UWP app I'm using is Calculator and Picture Viewer (only for viewing, I would never edit using that app).

To my experience, UWP apps are currently only used for meaningless things, like games and other bric-à-brac.

If UWP is ever supposed to be attended for anything else but pap, a feature like the suggested is essential.

[andriysavin]

@SetTrend I'm not saying the user should be given no choice to preserve or abandon her changes. And the fact the all major professional apps ask the user before closing doesn't mean this is the best way to do that. In my opinion, an app should just preserve it's state between restarts, so when the user/system reopens it later, it's in the same state it was before the restart, i.e. has unsaved changes, so user can decide if he/she want's to save the changes. A tradeoff could be to have that behavior for system-initiated (including manual user logoff/restart/shutdown) app exiting, and ask the user if the app is being closed by the user explicitly. However, if this behavior is not enforced by the system somehow (e.g. app can't cancel system-initiated closing), no one will bother to implement it in his/her app. An observation: users hate when Windows suggests them to restart to install updates. And that's primarily not because they need to interrupt their work, but because they will have to make many decisions about saving pending changes in their documents "right now", and then reopen all the documents and try to remember where they left off and which changes they were making recently. And at some point windows anyway forces a reboot, making decisions instead of the users. Thanks to MS Office it's already backing up changes, but not all apps do that. I don't think all this looks good to users, they just get used to it. And this is why this "classic" approach continues to appear in business requirements.

[Gavin-Williams]

@SetTrend "It wouldn't cross any of these users' minds to use an UWP app for their daily business." - I doubt they would even know they were using a well written UWP app if they weren't told. There is very little constraint on the capabilities and user experience of UWP applications. The fact that there are more sophisticated apps written on older platforms and frameworks is merely a matter of history, and inertia, it has little to do with the technology. Give me several million dollars and a few years, and I'll build you Word, or 3ds Max or nearly any other software using UWP, it's just software development, the same design and engineering decisions are to be made.

Do you actually believe that UWP can't be used to make software of any arbitrary level of sophistication? What part of the UWP development ecosystem actually stops a team from making nearly any software they desire?

And who would use Picture Viewer for editing? No one, so that means very little. Like I said before, I could build image editing software on the UWP platform that could rival photoshop in capabilities. It's technically straightforward, though I'm sure it would have it's challenges. The technology is not the issue, the real issue is that you have to invest massive resources into a new product that would be competing with Adobe and the other major graphics tools vendors, those software's having been built many years ago, and already mature. That's the real issue, it has nothing to do with UWP or .Net Framework, or Win32 technology. The language and libraries are not that different. UWP has access to the CPU and the GPU just like everything else. In a world where python is the most popular language, it's a bit cheeky saying UWP can't make real software.

PS. The fact that you say games are meaningless is a giveaway to your limited mindset and experience. It's a massive industry, that goes beyond anything you're likely to be doing. No offense, but your work may have little relevance or meaning to most people. While I see games making millions & millions of dollars every day.

[VagueGit]

Down vote from me @Gavin-Williams, not for your point of view but you are getting a bit aggressive toward @SetTrend

I do disagree though that you can write anything with UWP and nobody would know it is UWP. UWP apps will shutdown if running on battery and there is nothing the dev can do to stop it, other than require the user to keep the app in the foreground and jiggle the mouse occasionally. This is unacceptable for many business apps which are kept open all day.

There is no tabulated report writer for UWP. This is well documented elsewhere and is a known shortcoming. This is unacceptable for a a business app.

Microsoft tried to rewrite Office in UWP and failed.

You may well be capable of solving these issues @Gavin-Williams. It would have been nice if you had before now, as nobody else has.

[andriysavin]

@VagueGit I don't see any problems with tombstoning apps, this is just a matter of handling this correctly. Microsoft's UWP Office apps were pretty successful and did their job. The main reason MS abandoned them was not wanting to develop and support two versions of apps, that is - saving budget. Classic versions of Office apps support many technologies that UWP apps can't work with (I think of some OLE scenarios, macros etc.), and they were already more mature, so the choice was obvious. On the other hand, OneNote UWP app is currently the recommended app, and "classic" OneNote app is considered legacy and is not even installed with MS Office. OneNote UWP works great, and has no problems with handling UWP app lifecycle, and it's not a "toy app".

[marcelwgn]

@VagueGit UWP apps are not just "being shutdown" as soon as they are not being used, they are being suspended after some time being minimized. Also can you explain what exactly the problem with app suspension is? The app is not being killed and restarted after suspension but their state is restored after suspension which is hardly a problem I would argue.

@SetTrend Saying that there are only "meaningless UWP apps" is not really the case, and hurtful to those who are writing games (a multi billion dollar industry) and apps like Adobe Photoshop express, Onenote, Drawboard PDF or Nightingale to name a few.

Regarding the proposal, I think apps should get activated entirely showing the complete app, not just a small dialog asking to save something. As @Felix-Dev correctly noted, a lot of the time, just showing a "Do you want to save changes" dialog without any further context is not helpful if users just left the app open for the last few minutes/hours and don't know anymore what exactly they were editing. In addition to this, just showing a small dialog can become (and is for me) hard to notice. E.g. for my setup, a small dialog popping up on the secondary monitor is something I hardly notice, resulting in me having to actively search for that small dialog to finally be able to close the app.

[SetTrend]

@andriysavin:

I don't mind of UWP apps storing their document data in the background. That's OK and desirable. However, for professional users we need additional, user-centric, workflow UX.

I believe we should differentiate between frameworks for professional users (using software for generating value; e.g. Win32, WPF) and frameworks for leisure users (using software for wasting value; e.g. UWP, WinUI3).

UWP is a presentation framework, emphasizing on providing chrome, sparkling animations, etc. to the user. From my personal point of view, UWP is kind of a, how shall I write, "Barbie World" presentation layer, bringing fun and laughter to computing.

From my - purely personal - yet comprehensive observation, no professional office user is interested in anything that UWP provides: MS Store is a no-go. Sparkling animations are a waste of time. They're cringy, distracting from valuable data. So, they are a no-go. Touch screens are cumbersome and delicate to handle; a keyboard is much more flexible, faster and productive. So, touch screen GUIs are a no-go.

So, bringing professionality to UWP, like the one suggested by the original poster, would be necessary to have leisure align with professionality. From a user's point of view, I feel that's what Project Reunion is supposed to be about.

Actually, I don't know anyone using the UWP version of OneNote. It's too cumbersome. If being used at all, the desktop or the web version is being used.

@chingucoding:

Yes, I perfectly agree to your statement. Plus one.

[andriysavin]

@SetTrend Your UI looks only the way you define, regardless of UI framework. When using UWP, you don't have to use any fancy animations, and nobody forces you. UWP's UI stack is quite similar to WPF's, which you, I guess, treat as a "professional" framework. Both UWP and WPF allow you to draw UI how you want, starting with changing styles and ending with doing fully custom DirectX drawing. Some time ago I was working on a couple of quite professional WPF applications, and I can confidently say that those app could be written with the same or even higher quality using UWP UI stack in its today's shape.

As a user of many professional applications (Visual Studio is one of them) I don't feel I like all the modal dialogs popping and asking if I'm sure I want to close the window and if I'd like to save my changes. I want either autosave or state persistence, so I can decide later. Though I can't say for everyone in the world, but I see that all users of professional software I can observe get nervous when they are shown these modal dialogs.

[JaiganeshKumaran]

@BenJKuhn The problem is confirmAppClose is not just for showing a dialog. If an app uses is for saving data on close there's no need to switch to it which will create a bad experience since the app is anyway going to call ApplicationView.TryConslidateAsync after it finishes it's background save work that must run on termination. Instead there should be a flag which decides to activate or not which can be set before you register the event.

[JaiganeshKumaran]

For others: you should understand that UWP here means the app model and not the UI framework "UWP XAML". XAML is different and for that use the WinUI repo and not this repo

[andrewleader]

Thanks for all this feedback! This is actually a Windows platform bug and not a Project Reunion bug, so I've filed a bug with the platform team (internal bug #31583996) and asked them to follow up here with any updates.

I'll close this thread since this isn't an active issue with Project Reunion itself, but I appreciate you submitting this detailed report!

[soumyamahunt]

@andrewleader Thanks for the info, since I don't see any concrete conclusion on how this scenario could be handled, I am giving my thoughts here:

1. When user tries to close app with confirmAppClose capability while minimized the app process becomes active from suspended without displaying the window (Application.Current.LeavingBackground event is triggered).
2. Then Windows.UI.Core.Preview.SystemNavigationManagerPreview.SystemNavigationManagerPreview.CloseRequested event will be triggered which then app does anything it wants to do when close is requested. Don't display the app window just yet.
3. App uses Windows.UI.Core.Preview.SystemNavigationCloseRequestedPreviewEventArgs.Handled to indicate whether to automatically close the app or prompt user for additional input. This flag can be checked by system and only display the app window if the value is true, otherwise app can be closed silently without any additional prompt.

[Poopooracoocoo]

@andrewleader Any updates on the internal bug?