[uwp] Proposal: Allow bringing application in foreground on drag-and-drop from another app

[jtorjo]

Proposal: [uwp] Proposal: Allow bringing application in foreground on drag-and-drop from another app

Summary

There should be a way to bring the application to foreground on drag-and drop - whether programmaticaly or manually.

Rationale

The reason I want this is to handle drag and drop (of files/folders) properly. My app needs to be full screen (since it's got plenty of information to show). When the user drags something, I want to contextually show him where to drop his files.

Right now, this is not possible, because I can't bring the app in foreground

This has been asked time and time again: https://social.msdn.microsoft.com/Forums/en-US/bf42b98f-1e35-4699-9001-ca3a733f3cb2/uwp-how-to-bring-the-app-to-foreground-on-drop-event?forum=wpdevelop https://developercommunity.visualstudio.com/idea/560137/bring-the-app-to-foreground-on-drop-event.html https://stackoverflow.com/questions/42176570/bring-uwp-app-in-foreground

This sandbox-over-micro-management in UWP is starting to get to me. There are valid reasons for allowing an app to bring itself into the foreground. And no, the "CompactOverlay" is not the solution - I have no idea why anyone would ever use that.

Open Questions

There is a huge disconnect between what us - developers - really want, and the things that are in this sandboxed environment.

I really hope, once WinUI 3.0 is complete, someone (or some team) will go over all the sandbox limitations, and simply remove those that don't make sense (like, the Suspend API, for instance).

[marcelwgn]

There are valid reasons for allowing an app to bring itself into the foreground

There are also valid reasons to block apps from having them force their way to the foreground.

There is a huge disconnect between what us - developers - really want, and the things that are in this sandboxed environment.

The sandbox is not designed to be perfect for every app. If you run into issues to often, you might want to consider switching to something else, though I can see that this often will be hard given the performance benefit of UWP.

Also something important is that there is a third party in that equation that is the most important: The users. You can have app models where apps are allowed to everything, and you can have a sandboxed model which protects the users as good as possible. And I think some areas you pointed out that are annoying to work around are just potential risks for users. The most important part of developing an app should be: How do users feel with it?

The Sandbox of UWP is exactly trying to improve that behavior. Of course there are some limitations that are very hard to justify, but I think allowing apps to ALWAYS get in the foreground is not one of those things. What prevents apps from just interfering all the time if we allow that?

And no, the "CompactOverlay" is not the solution - I have no idea why anyone would ever use that.

It might not be in your case, but there are a lot of use cases where the compact overlay mode is just much better to use, e.g. Calculator or the old Netflix app. Not having to think about where I put an app but just knowing it is always on top can sometimes be really helpful.

The reason I want this is to handle drag and drop properly. My app needs to be full screen (since it's got plenty of information to show). When the user drags something, I will contextually show him where to drop his files.

I think the better and more accessible solution would be to have a way to put an app in foreground when it has received something via drag and drop, instead of allowing setting foreground everywhere.

[jtorjo]

The reason I want this is to handle drag and drop properly. My app needs to be full screen (since it's got plenty of information to show). When the user drags something, I will contextually show him where to drop his files.

I think the better and more accessible solution would be to have a way to put an app in foreground when it has received something via drag and drop, instead of allowing setting foreground everywhere.

While I disagree with a lot of what you said, I would be ok with having this, for starters.

[jtorjo]

The sandbox is not designed to be perfect for every app. If you run into issues to often, you might want to consider switching to something else, though I can see that this often will be hard given the performance benefit of UWP.

I would have done this looooooooong time ago, had I truly had a choice. M$ locked me into UWP when it made win2d UWP-only (which clearly was the original intent)

[Felix-Dev]

As @chingucoding said, if the user drops something onto an app which is not in the foreground, the app should be allowed to activate itself (brought to the foreground and got focus). If I, as the user, drop something onto the app which then needs to be processed further by me, it is my expectation as a user that the app will be activated then. I should not have to explicitly bring it to the foreground myself (such as clicking its taskbar button, using the Task View or clicking on its app window) to complete the drop operation.

This is similar in nature to my request here and both these issues boil down to: If a user initiated action requires further input from them to be completed, the developer should be able to activate the app even if it is currently not the foreground app.

[jtorjo]

This is similar in nature to my request here and both these issues boil down to: If a user initiated action requires further input from them to be completed, the developer should be able to activate the app even if it is currently not the foreground app.

I am in 100% agreement with you. And about your issue - yes, it definitely should work as you describe, I wasn't even aware of this issue, 'cause I would have definitely filed a request myself ;)

[Felix-Dev]

@jtorjo Would you agree in editing this issue (such as its title and summary) so we have it narrowly defined for the specific drag & drop app activation scenario?

In addition - if not yet done so - you should probably file a feedback hub item (and linking to this proposal perhaps) and also tag Ben Kuhn here.

With that you did everything we were told to do regarding sbmitting UWP feedback and we will then have to wait and see if this issue will be worked on in the future.

[mdtauk]

Win32 made many many things possible for Windows app developers.

In hindsight, maybe it should not have done.

WinUI Desktop and UWP are Microsoft's considered approach, trying to put the user before the developer, and being judicious about what they allow applications to do.

For requests like this, where a useful (to the user) case is made, I think that will help the relevant teams look fondly on the suggestion. But if you make a suggestion that is or can potentially be anti-user - it will most likely be ignored.

[Felix-Dev]

WinUI Desktop and UWP are Microsoft's considered approach, trying to put the user before the developer, and being judicious about what they allow applications to do.

@mdtauk WinUI Desktop is MSs offer to developers to be able to ship an app featuring a modern UI/UX while not having to deal with the limitations imposed upon them by the sandbox/UWP app model.

[mdtauk]

WinUI Desktop and UWP are Microsoft's considered approach, trying to put the user before the developer, and being judicious about what they allow applications to do.

@mdtauk WinUI Desktop is MSs offer to developers to be able to ship an app featuring a modern UI/UX while not having to deal with the limitations imposed upon them by the sandbox/UWP app model.

Yes, except WinUI 3 in general needs to work with UWP also, so any APIs or surfaces need to work on both.

[Felix-Dev]

We have a good example with the new Window class WinUI 3 will introduce where depending on the underlying app model (assuming a "win32 app model") some APIs will work or not. For example, it will support features for classic Win32 apps even if those are not yet available on UWP, such as hiding a window from the taskbar.

WinUI Desktop will thus provide Win32 app developers with a familiar experience even though there might not be support for such experiences when using WinUI in a UWP app.

@mdtauk Btw, we should probably hide this discussion, and whatever reply you might want to give to this post as it is not relevant to the specific issue in question here. The Windows team looking at this thread should not be "distracted" by us talking about WinUI and how it works in desktop or UWP apps.

[jtorjo]

@jtorjo Would you agree in editing this issue (such as its title and summary) so we have it narrowly defined for the specific drag & drop app activation scenario?

@Felix-Dev Done.

@BenJKuhn Here's the ticket on feedback hub: https://aka.ms/AA8b8jh

[jtorjo]

WinUI Desktop and UWP are Microsoft's considered approach, trying to put the user before the developer, and being judicious about what they allow applications to do.

@mdtauk I will very likely get flamed here, but I'm really curious where is the research about whether users actually care about this or not. And basically, most of the sandbox restrictions except dealing with Files/Folders:

• do users really care about whether an app brings itself into the foreground? (when it makes sense)
• do users really care about whether an app tries to maximize itself or change its size? (again, when it makes sense)

(and clearly, a user that doesn't want an app to behave that way can simply either tell its author, or simply uninstall the app; how about, if an app "violates" a so-called restriction, Windows will add a button next to "close" in the title bar - where user can instantly uninstall the app?)

[Felix-Dev]

@jtorjo The way I see it, with the sandbox, these app restrictions are ON by default. You as a user don't have to hope that the developer of the app will listen to you and fix the issues you have with the app just doing as it pleases. You could uninstall the app, but what if the app is vital for you and and you can't really avoid using it?

In times like these a great example is Microsoft Teams. Many now have to use the desktop app because otherwise they couldn't continue with their work and earn money. The sad story here is that while this product is from the same company that created the UWP app model, the similarities more or less end there. Unbelievable but true, the desktop client sets itself as a start-at-log-in app without asking for the user's consent. Talking about consistency at MS.

The point I want to make is this one: Sometimes, even outside of your control, you are forced to use products where you are at the mercy of the developer alone to build a software which puts the user first and not itself. The developer, however, might have different interests than you as the user. And they will use their market status to push primarily their vision of the product.

Raymond Chen's blog is full of examples where some software companies thought themselves clever and wrote code which put their product first. No matter the impact on the rest of the system, as long as their app got best access to the user device's resources they considered it a win. Doesn't matter if that negatively impacts the workload of some users.

Enter the sandbox here. It restricts exactly these attempts by developers who want to put their app first on the user's system, no matter the user's setup. If you think you have noteworthy information to show the user, send a notification. Let the user decide whether they actually deem the information important in their current workflow and should thus stop their current work and switch to your app context. If you think your app is so important it should run on the user's device all the time, let the actual device owner decide if they agree with you.

These are just two examples where the sandbox creates a much improved experience for the user.

And speaking as a user, if an app suddenly does something I as the user didn't tell it to do, then that's frustrating. You say "when it makes sense". The fundamental issue here is "when it makes sense" might be answered differently by the user than by the developer. The developer knows nothing about how the user uses their device outside of running their app. The developer might think "given app event x, this is really important and the user must know about it RIGHT NOW". However, the developer has no clue what the user is doing in this very moment. "Right now?" The user might be busy working on something and suddenly they are interrupted by this app. Without warning.

The sandbox prevents events like these from happening. When great theory matches great implementation, this can be a stress-free user experience (as demonstrated with the notification example). When great theory matches bad implementation, the experience is unsastifying for everyone, the developer and the user.

PS: I will try to find a few Raymond Chen blog posts. If successfull, I will add them to this post.

[jtorjo]

@Felix-Dev Many many thanks for the detailed explanation. Deeply appreciated!

Probably my anger comes from the fact that a lot of sandbox constraints have not been given any afterthought. Like, your issue, which makes complete sense - why should the app behave differently when closed from minimized or from normal state? Same here - this has been known for years, yet nothing has been done. And you know my other WinRT thread - they're preaching "user first", but a lot of the user experiences are far from stellar.

And more, I don't really know of any non-trivial UWP coming from Microsoft. So while us, the developers, spend countless hours dealing with such issues, compilation being insanely slow, filing bugs and such, they're either using Electron or win32.

[contextfree]

@mdtauk I will very likely get flamed here, but I'm really curious where is the research about whether users actually care about this or not. And basically, most of the sandbox restrictions except dealing with Files/Folders:

• do users really care about whether an app brings itself into the foreground? (when it makes sense)
• do users really care about whether an app tries to maximize itself or change its size? (again, when it makes sense)

I don't have any quantitative data of course, but if you do a search for "focus stealing" you can see that at least some people get really upset about it, e.g.:

https://www.change.org/p/microsoft-stop-focus-stealing ("Petition to Microsoft: Stop Focus Stealing!")

https://www.urbandictionary.com/define.php?term=focus%20stealing ("A very annoying feature in windows where an application foribly brings itself to the front (aka steals the focus). Can also be when you're filling out a form on a website and what part of it you've selected to enter text into suddenly changes.")

https://www.reddit.com/r/windows/comments/4gx1fl/why_does_microsoft_now_permit_focus_stealing/ ("Why does Microsoft now permit focus stealing?")

An interesting theme in the posts and comments in these and other pages is that most people seem to intuitively think of this as an OS problem, rather than a problem with individual applications, and expect it to be solved at the level of the OS instead of at an application level.

[Felix-Dev]

@jtorjo

I feel you. The UWP sandbox is a laudable concept yet in many cases, MS has not yet managed to implement the sandbox in a user-friendly way across the board. That's an important point to keep in mind in any discussion about the sandbox. One of the fundamental issues I'm pointing out in my specific UWP App Model proposals is definitely not of the theme "Sandbox vs developer". No, it's about the sandbox in some cases just being "super narrow with what it allows" that it really is in fact "anti-user" there.

The sandbox implemenation in its current form is far from being perfect speaking from the perspective of a developer and a user and with proposals like these we are doing our part in trying to improve the situation. Still, we can only do so much and we are at the mercy of MS to actually commit resources to make the sandbox experience great. Hopefully we will learn more about MSs plans on this subject in the coming months.

[shaheedmalik]

It's already possible to do this via dragging to subject to the Taskbar but it doesn't work while in Tablet Mode. This aspect is on the shell team.

[jtorjo]

https://www.change.org/p/microsoft-stop-focus-stealing ("Petition to Microsoft: Stop Focus Stealing!")

https://www.urbandictionary.com/define.php?term=focus%20stealing ("A very annoying feature in windows where an application foribly brings itself to the front (aka steals the focus). Can also be when you're filling out a form on a website and what part of it you've selected to enter text into suddenly changes.")

https://www.reddit.com/r/windows/comments/4gx1fl/why_does_microsoft_now_permit_focus_stealing/ ("Why does Microsoft now permit focus stealing?")

@contextfree Thanks for pointing this out! I was not aware of it.

[jtorjo]

@Felix-Dev

I feel you.

Thanks :)

The UWP sandbox is a laudable concept yet in many cases, MS has not yet managed to implement the sandbox in a user-friendly way across the board. That's an important point to keep in mind in any discussion about the sandbox. One of the fundamental issues I'm pointing out in my specific UWP App Model proposals is definitely not of the theme "Sandbox vs developer". No, it's about the sandbox in some cases just being "super narrow with what it allows" that it really is in fact "anti-user" there.

Got it, it makes a lot of sense. Yes, I'm totally fine with the sandbox concept as well, practice is killing us ;)

The sandbox implemenation in its current form is far from being perfect speaking from the perspective of a developer and a user and with proposals like these we are doing our part in trying to improve the situation. Still, we can only do so much and we are at the mercy of MS to actually commit resources to make the sandbox experience great. Hopefully we will learn more about MSs plans on this subject in the coming months.

Agreed, lets hope for the best :)

[Felix-Dev]

This issue should probably be moved to Project Reunion @jevansaks @StephenLPeters

@jtorjo FYI.

[jtorjo]

@Felix-Dev thanks, I'm assuming only @jevansaks or @StephenLPeters can move it, righ?

[stevewri]

@Ram-G : This proposal would probably require some window manager work (to perform the activation) and shell work, but from a Reunion feature perspective it sounds like something drag and drop would drive. Does that make sense?