Bug 441074 - windows with "keep above others" option don't stay above windows in "windowed fullscreen" mode.
Summary: windows with "keep above others" option don't stay above windows in "windowed...
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Arch Linux Linux
: LO normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: usability
: 430997 441413 445366 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-08-17 09:14 UTC by redartofcode
Modified: 2021-11-16 14:17 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
PiP firefox video pop up above a game (3.62 MB, image/png)
2021-09-22 12:39 UTC, redartofcode
Details

Note You need to log in before you can comment on or make changes to this bug.
Description redartofcode 2021-08-17 09:14:59 UTC
SUMMARY
I am trying to create a game overlay (something like gamebar in windows 10), and i need my overlay to stay reliably on top of the game window. so, it has the "keep above others" option. when i run a game in window mode, everything works well. but once i go into windowed fullscreen mode, and i focus the game window by clicking on it, my overlay or any app like firefox with "keep above others" enabled goes into the background. i don't know if this is intended behavior, but on windows, i don't have this issue and multiple overlays similar to mine work fine. for now, i just set the game option "keep below others" enabled, and now my overlay can stay on top. 

STEPS TO REPRODUCE
1. Open any lutris game in windowed fullscreen mode. 
2. set any other app's window as "keep above others"
3. click on the game window to focus it and watch the other app's window go into background

OBSERVED RESULT


EXPECTED RESULT
When the game is running in windowed fullscreen, the apps with "keep above others" option enabled must be visible and not go into background. if the game is in fullscreen, then maybe the apps should go into background? that's for the devs to decide. this is how it works on windows atleast. 

SOFTWARE/OS VERSIONS
Windows: 10
macOS: 
Linux: 5.10
(available in About System)
KDE Plasma Version: 5.22.4
KDE Frameworks Version: 5.85.0
Qt Version: 5.15.2

ADDITIONAL INFORMATION
https://bugs.kde.org/show_bug.cgi?id=430997 is similar, but its talking about fullscreen windows while i am talking about windowed fullscreen mode.
Comment 1 David Edmundson 2021-08-20 22:09:16 UTC
Yes, it is intentional as per:
https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#STACKINGORDER

As a KDE specific override you can copy what we do for "critical notifications" which is a KDE specific window type you can set your window to.
Comment 2 Nate Graham 2021-08-23 19:01:36 UTC
*** Bug 441413 has been marked as a duplicate of this bug. ***
Comment 3 Nate Graham 2021-08-23 19:02:22 UTC
*** Bug 430997 has been marked as a duplicate of this bug. ***
Comment 4 Nate Graham 2021-09-22 12:08:33 UTC
We should consider shipping KWin with a window rule to override this by default, since it's clearly something users expect, even if it violates the spec. But users don't care about the spec, they care about the end result. :) If we ship a window rule, then technically KWin itself is still following the spec, but users are availing themselves of a shipped-by-default local override for it. :)
Comment 5 redartofcode 2021-09-22 12:37:15 UTC
just to add. i made a new issue https://bugs.kde.org/show_bug.cgi?id=442720 which is related to this. but more about pointer staying grabbed when i hover/click on the clearly top windows which are using transient_for or critical notification settings. mentioning just in case devs want to consider both the issues before coming to a decision :) 

about the spec, 
https://specifications.freedesktop.org/wm-spec/wm-spec-1.4.html#STACKINGORDER  , 
I raised a similar issue with i3, and dev said that the stacking order is more of a recommendation and explicitly says that window managers are free to choose differently when it makes sense. https://github.com/i3/i3/issues/4478#issuecomment-900493830

so, keeping the "stay above others" windows on top of windowed fullscreen might technically not be breaking the spec. there's also critical notifications which already are going above not just windowed fullscreen, but fullscreen windows.

for both issues, one of the main use cases is overlays for games, also recently firefox has a feature to "pop out" the video player part and drag it around.its called picture in picture feature. people might want to watch news/music videos/cat videos/game walkthroughs etc.. while playing a video game or some other fullscreen thing like terminal. allowing the PiP video be clickable is important as it will allow me to pause it.
Comment 6 redartofcode 2021-09-22 12:39:34 UTC
Created attachment 141792 [details]
PiP firefox video pop up above a game
Comment 7 Nate Graham 2021-11-12 22:55:41 UTC
*** Bug 445366 has been marked as a duplicate of this bug. ***
Comment 8 Petr Kejval 2021-11-13 07:50:41 UTC
So it can be set already at user level or should we wait for you to implement it into Plasma?
Comment 9 Nate Graham 2021-11-14 03:01:30 UTC
You can do it at the user level today with KWin window rules. This bug report is about us shipping such a window rule for everyone by default.
Comment 10 Petr Kejval 2021-11-15 14:04:54 UTC
Can you tell me how to do it at user level? I tried every window type for VLC but it isn't on top of fullscreen window. Can you tell me how to set windows type "critical notification" for VLC in Plasma 5?
Comment 11 Nate Graham 2021-11-16 14:17:13 UTC
I don't know, sorry.