Port UWP taskbar behavior when fullscreen to Win32 apps

[MarcAnt01]

Proposal: [Port UWP taskbar behavior when fullscreen to Win32 apps]

Summary

If a UWP app is in full screen if I swipe up from the bottom part of the screen with touch or otherwise with a touchpad/mouse I just hover the bottom part of the screen. In Win32 apps nothing happens. The only way to switch to apps is using multitasking view, which is quite annoying. Another useful feature of this uwp feature is the ability to retrieve the title bar analogously by swiping down from the upper part of the screen or putting the mouse hover on top. This could be invoked with the useful shortcut Win+Shift+Enter like in UWP apps so that you can also manually opt it in

Rationale

• Having the same behaviour in Win32/UWP apps is ok for the purpose of Project Reunion
• Being able to switch among apps or just check the time or info on taskbar would be made definitely easier and with basically no drawback

Scope

Capability	Priority

Important Notes

Open Questions

Will this behavior cause problems to games where the taskbar could be popping-out continuously? My idea is to make this one the default behavior, even if an option to disable it should be present. For those who continue to argue about games, I just think that they aren't the main usage of WinAppSDK, that I think is instead new generation WinUI 3 apps

[JaiganeshKumaran]

The problem is UWP apps use the built-in API to do this which handles this correctly but Win32 apps don't have such API and have their own methods of achieving so it's up to the developer unless Microsoft provides a built-in way to go full screen in a Windows desktop app. I did ask for a built-in API because many full screen implementations are broken and don't work correctly.

[riverar]

This proposal is incomplete (e.g. scope section is invalid).

[MarcAnt01]

This proposal is incomplete (e.g. scope section is invalid).

[riverar]

@MarcAnt01 Optional != Provided w/ invalid values. I understand it's minor but I read it and was briefly confused.

[MarcAnt01]

@MarcAnt01 Optional != Provided w/ invalid values. I understand it's minor but I read it and was briefly confused.

Ah yes, removing it might make sense. Done

[sylveon]

I think this outright cannot work for exclusive full screen apps (because DWM is not involved here, so start cannot show up over the game), and might cause more pain than benefits for some kinds of games or interfaces.

For example, some games requiring the pointer might have you jerk quickly around the screen, meaning you might hit the bottom. Thus the taskbar pops up and breaks DirectFlip, making the game become stuttery until the taskbar goes away.

Some FPS games don't reset the pointer position often enough to the center, so sometimes you might hit the bottom and the same issue happens (I've had that one when using Mouse Without Borders). It gets even worse if you end up clicking on the taskbar too, because you could trigger long loading processes (e.g. Visual Studio or another game is pinned to the taskbar).

In the cases of interfaces, I think of YouTube where somebody would want to access settings or something and because the mouse went to the bottom of the screen, start pops up and completely blocks out the settings icon, forcing the user to move their mouse back towards the middle, wait for the taskbar to go away and then move their mouse back towards the settings icon more carefully to not hit the bottom of the screen.

In all 3 examples, this is very frustrating behavior.

[MarcAnt01]

I think this outright cannot work for exclusive full screen apps (because DWM is not involved here, so start cannot show up over the game), and might cause more pain than benefits for some kinds of games or interfaces.

For example, some games requiring the pointer might have you jerk quickly around the screen, meaning you might hit the bottom. Thus the taskbar pops up and breaks DirectFlip, making the game becomes stuttery until the taskbar goes away.

Some FPS games don't reset the pointer position often enough to the center, so sometimes you might hit the bottom and the same issue happens (I've had that one when using Mouse Without Borders). It gets even worse if you end up clicking on the taskbar too, because you could trigger long loading processes (e.g. Visual Studio or another game is pinned to the taskbar).

In the cases of interfaces, I think of YouTube where somebody would want to access settings or something and because the mouse went to the bottom of the screen, start pops up and completely blocks out the settings icon, forcing the user to move their mouse back towards the middle, wait for the taskbar to go away and then move their mouse back towards the settings icon more carefully to not hit the bottom of the screen.

In all 3 examples, this is very frustrating behavior.

I find it way more annoying not to have a way to go back in certain scenarios. Using touch it's even worse, because sometimes you cannot go back unless there's a "go back button". I agree it's not a perfect behavior, but the one which is less annoying in the overall imho

[Gavin-Williams]

This must be an optional behavior. UWP is already hobbled by this behavior and IMO not suitable for game development on desktop because of it. And that's because we cannot fully suspend overlay in UWP, and so Windows captures the top and bottom pixel row of the screen for taskbar / titlebar activation. Even with the mini-bar, it is still captured. That is a breaking feature for many games, they could not be run without incident, because this mouse capture blocks normal interaction such as camera pan where the hardware mouse is used. But software mouse doesn't get around it either. Besides those titles that use the screen edge already, the issue with titlebar and taskbar popping up uninvited is already observed for games such as Minecraft which do capture the mouse and keep it centered. It just shouldn't happen if the app developer doesn't want it happening.

You could propose an OS feature to enable taskbar activation, or restrict it to swipe-up only, and no mouse responsiveness.

I've just moved back to Win32 after a few years learning to code on UWP, I love UWP but this is one of the few boxes I've crossed for UWP that has caused me to abandon it. Because by now, Microsoft would have given us an option to disable overlay if they were serious about supporting game development on UWP. They are not seemingly. It was a relief to open my Win32 app stub and move the mouse around without any overlay popping up. That is the control I need to make games. Games have particular UI/UX needs that not all app dev's understand. And I bet there are even some apps that require full control of the view space, and in those cases, it's just as important that this is optional.

See my counter proposal from 2020...

Proposal: Provide API to disable TitleBar and TaskBar popups #2027

[Balkoth]

If a UWP app is in full screen if I swipe up from the bottom part of the screen with touch or otherwise with a touchpad/mouse I just over the bottom part of the screen.

This sentence does not make any sense.

[MarcAnt01]

If a UWP app is in full screen if I swipe up from the bottom part of the screen with touch or otherwise with a touchpad/mouse I just over the bottom part of the screen.

This sentence does not make any sense.

If you want to discuss about it, starting with it "does not make any sense " isn't a good idea, since I don't usually like to answer to rude sentences

[Balkoth]

There is no discussion, because i do not understand your problem, because your description does not make any sense. Please write an english sentence. Have a nice day.

[MarcAnt01]

There is no discussion, because i do not understand your problem, because your description does not make any sense. Please write an english sentence. Have a nice day.

If you don't understand, you may ask for an explanation like polite people do. Go and be rude somewhere else, bye 👋

[Balkoth]

I think it is rude to post such a useless description. You came here to propose something. Making your point clear in the OP is something YOU should strive for.

Now you have answered multiple times and still not made your point clear.

[riverar]

OK folks let's calm down. Does the updated description help? It was a typo (over vs. hover).

[Balkoth]

At least it is an english sentence now. I am sorry but i could not figure this out. I still do not think it is a good description, because i am expected to know what the UWP behaviour is.

My best guess is that he wants that the taksbar shows itself when you hover there?

[MarcAnt01]

@Balkoth If you don't understand something, it doesn't mean that my issue is "useless" and not clear, also have you noticed that 7 people added a thumb up emoji and that I'd had a conversation with @sylveon about possible drawbacks of this behavior? You came here just shouting at me because I forgot the h before a word. Try to question yourself, before blaming other people next time

[MarcAnt01]

If we wanna go back to the point of the issue, the taskbar using mouse/touchpad appears if you put the cursor for some millisecs in the bottom part of the app. Using touch you can see it swiping up from that area (beginning from out of the screen). This happens only in UWP app as far as I know. Feel free to ask any question if it's still not clear to you

[riverar]

OK, so maybe this will help:

• Title: Allow access to Taskbar when desktop app is fullscreen
• Summary: When Universal Windows Platform (UWP) apps are in full-screen mode, users can access the Taskbar by moving the mouse to the edge of the display where Taskbar resides. This proposal seeks to extend this behavior to desktop apps built against the Windows App SDK.

[Gavin-Williams]

If you're going to force this on us, then we also need a way to completely suspend mouse events / mouse position except for delta's while in fullscreen to prevent the titlebar and taskbar from being activated. And just to be clear, this would force us (game developers and some app developers) to use a software mouse in all cases because I don't see any proposal here to resolve the issue of the actual mouse capture problem - there can't be any interaction with the mouse and explorer while a game is running, so no overlay popup triggers. And yes, you are exactly asking for something that many of us cannot permit - it will kill Windows AppSDK for us, just as UWP is unusable.

[MarcAnt01]

If you're going to force this on us, then we also need a way to completely suspend mouse events / mouse position except for delta's while in fullscreen to prevent the titlebar and taskbar from being activated. And just to be clear, this would force us (game developers and some app developers) to use a software mouse in all cases because I don't see any proposal here to resolve the issue of the actual mouse capture problem - there can't be any interaction with the mouse and explorer while a game is running, so no overlay popup triggers. And yes, you are exactly asking for something that many of us cannot permit - it will kill Windows AppSDK for us, just as UWP is unusable.

I think an option to disable this behavior should be present, even if the uwp behavior should be default.

[Balkoth]

I don't think that forcing such a disruptive behaviour on all applications by default is a good idea. There is a reason why fullscren win32 apps never did this. If an option for this is considered, the default should be that it is disabled.

[sylveon]

Yes, it's very disruptive to both the user and application, and the point I was making before. It can't even work in the case of exclusive fullscreen, too, making the taskbar behavior inconsistent.

An option for the apps themselves to disable the behavior fails to consider the thousands of games pre-App SDK that would be negatively affected by this change, and cannot be updated anymore. The UWP behavior should not be default, but rather a per-app opt-in.

[JaiganeshKumaran]

I think the UWP behaviour should be the default for new desktop apps using WinUI 3 and others through a new simplified API for full screen but not apps which use their own methods including existing ones. Further more, a new value could be added to the enumeration FullScreenSystemOverlayMode that would suppress task bar and title bar overlay plus give exclusive full screen for the window.

[MarcAnt01]

Yes, it's very disruptive to both the user and application, and the point I was making before. It can't even work in the case of exclusive fullscreen, too, making the taskbar behavior inconsistent.

An option for the apps themselves to disable the behavior fails to consider the thousands of games pre-App SDK that would be negatively affected by this change, and cannot be updated anymore. The UWP behavior should not be default, but rather a per-app opt-in.

You see how this behavior is disruptive for games, but you don't seem to see how the Win32 behavior is disruptive for touchpad users or simply people that want to go back without using a keyboard (especially those who are using only a mouse or a touch device).

[Balkoth]

What are those fullscreen apps that would need sich functionality anyway? There now have been a number of cases in which this feature would break apps, while you have given none where this would be useful.

[sylveon]

Most fullscreen apps do provide a way to leave the app with a mouse, as a fullscreen app without a way to exit is called a virus. The only apps I've seen which provide a keyboard-only way to exit it are games which require a keyboard to play to begin with, so it isn't a concern here.

The amount of legitimate fullscreen apps without a way to leave is low, so this feature would negatively affect thousands of legit apps just to make a few apps (which are still unnamed, please give examples) more usable from touch.

[winston-de]

The way I see it, it's not simply about being able to exit full screen, but being able to access to the taskbar while in a full screen is useful. It's annoying to have to exit full screen just to do something simple. For example, to quickly check the time or the status of an operation in another app while watching a YouTube video full screen. Also, I agree that this would break many apps, and should be opt in.

[MarcAnt01]

The way I see it, it's not simply about being able to exit full screen, but being able to access to the taskbar while in a full screen is useful. It's annoying to have to exit full screen just to do something simple. For example, to quickly check the time or the status of an operation in another app while watching a YouTube video full screen.

Also, I agree that this would break many apps, and should be opt in.

Exactly, imagine I am watching a YouTube video and want to know the time or just check notifications. In the old Edge I would just swipe up from the bottom, now I have to exit full screen and this sounds like a terrible UX to me. Most apps aren't games, so it makes no sense to enforce a behavior that makes actually sense only on games.

[Balkoth]

It makes no sense to enforce such behaviour for your niche scenario. Most apps do not need this, as they do not run fullscreen. If an app willingly chooses fullscreen, it willingly chooses that no other os elements are visible or reachable.

[MarcAnt01]

It makes no sense to enforce such behaviour for your niche scenario. Most apps do not need this, as they do not run fullscreen. If an app willingly chooses fullscreen, it willingly chooses that no other os elements are visible or reachable.

I could say about your scenario to be niche and that most apps do need these and an app choosing fullscreen just wants additional space and could want system os elements to be visible 🤷

[Balkoth]

You would be lying if you would do that 🤷‍♂️

[MarcAnt01]

Ok, thanks for providing your objectively superior point of view

[vitordelucca]

Another useful thing would be to have the shortcut full screen behavior that UWP does. Every UWP, if you press Win+Shift+Enter, it goes full screen. I find that super useful.

[MarcAnt01]

Another useful thing would be to have the shortcut full screen behavior that UWP does. Every UWP, if you press Win+Shift+Enter, it goes full screen. I find that super useful.

I never use keyboard shortcuts, but this sounds really useful. Adding to the description

[sylveon]

Most apps aren't games, so it makes no sense to enforce a behavior that makes actually sense only on games.

But games are a significant portion of apps which make use of fullscreen, so they must be considered.

[MarcAnt01]

Most apps aren't games, so it makes no sense to enforce a behavior that makes actually sense only on games.

But games are a significant portion of apps which make use of fullscreen, so they must be considered.

Apps which use fullscreen =! apps targeted for WinAppSDK

[Balkoth]

You contradict yourself, the title and your description states win32 which means just about every application.

[MarcAnt01]

You contradict yourself, the title and your description states win32 which means just about every application.

You cannot port uwp behavior to uwp, because it's already there

[vitordelucca]

You contradict yourself, the title and your description states win32 which means just about every application.

This is a WindowsAppSDK repo, not Feedback Hub or Windows OS issue repo. Any feedbacks here it's for apps using WindowsAppSDK, it's crystal clear.

[Balkoth]

You realize that in order for this to work, changes have to made at the OS level. Both UWP and WIN32 have their roots in the OS itself.

[MarcAnt01]

And your point being? Project Reunion feature requests might require changes in the system itself to be implemented

[Balkoth]

My point is exactly your point.

[sylveon]

The original text of the issue never mentionned the App SDK, so I assumed this was an attempt to get the feature to all apps, regardless of whether they are using the App SDK or not. This could have been clearer.

If it's the case that the change is suggested for App SDK only, then I don't mind as long as there's an easy way to completely opt-out of it.

[MarcAnt01]

The original text of the issue never mentionned the App SDK, so I assumed this was an attempt to get the feature to all apps, regardless of whether they are using the App SDK or not. This could have been clearer.

If it's the case that the change is suggested for App SDK only, then I don't mind as long as there's an easy way to completely opt-out of it.

Yep, ofc as Vitor pointed this isn't feedback hub, so I didn't think it was necessary to point that out that this ticket is aimed at it

[mveril]

I think AppWindow need to support two behaviors, what I will call TaskBar overlay and TitleBar overlay (that are mandatory on UWP). This two behaviors can also be dissociated to have a "À la carte" behavior. For the TitleBar it should also be interesting to automatically show an "Exit fullscreen" button in place of the maximize button exactly like UWP fullscreen windows.

[Gavin-Williams]

"Most apps aren't games, so it makes no sense to enforce a behavior that makes actually sense only on games." ROFL. I've played more game that I've used apps. And most people I know will be in that category. And on mobile devices, yes, there are more games released every year than apps.

[Gavin-Williams]

"Apps which use fullscreen =! apps targeted for WinAppSDK" Is that so? Where does Microsoft say that? Where do they say they have no intention of supporting fullscreen apps and games in Windows API's moving forward?

[Gavin-Williams]

This is a WindowsAppSDK repo, not Feedback Hub or Windows OS issue repo. Any feedbacks here it's for apps using WindowsAppSDK, it's crystal clear.

You say it's crystal clear, but I agree with Balkoth, WindowsAppSDK is for all apps, not just some apps. Isn't project reunion meant to be a unifying platform. Or are particular parties trying to keep things separated still and perhaps even separate things even more. WIndowsAppSDK is not just for your kind of apps, it's for my kind of apps too, which includes games.

I really worry that many people in the 'app' community are trying to take ownership of WindowsAppSDK. One of UWP's strengths was that it could target XBox, Hololense, UWP was clearly a platform that supported game development. WindowsAppSDK must encompass game development equally. It is after all meant to be a successor to UWP, and to legacy Win32 app development approaches. It can't do that if people keep dismissing the single largest category of apps - games.

[riverar]

@andrewleader Can we kill this issue? Nothing good to be had here, I'm afraid.

[MarcAnt01]

I think the new behavior of tablet optimized taskbar, that makes it always accessible with a swipe from the bottom completely solves this problem at least for touchscreen, I don't don't if it's worth to keep this open for mouse/touchpad