Created attachment 139801 [details] Firefox running natively on Wayland SUMMARY Unfortunately I do not know steps to reproduce this bug consistently. Sometimes Plasma panel remains visible when I activate the full screen mode of apps that run natively on Wayland like Firefox, Kate and Gwenview (please see the attached screenshots). Apps running on Xwayland like Firefox, Opera and Vivaldi internet browsers are not affected. EXPECTED RESULT full screen mode of apps running natively on Wayland should always work SOFTWARE/OS VERSIONS Operating System: KDE neon Unstable Edition KDE Plasma Version: 5.22.80 KDE Frameworks Version: 5.84.0 Qt Version: 5.15.3 Graphics Platform: Wayland
Created attachment 139802 [details] Gwenview
Created attachment 139803 [details] Kate
I was experiencing this about 2 months ago on git master, but no longer can.
it's still reproducible on neon unstable at least with Firefox.
I don't know if the games I'm running are native Wayland apps or not but I noticed the same happens on Plasma 5.22.4 with DuckStation emulator and Sonic Robo Blast 2 Kart. I can also confirm it happens with Gwenview. Sometimes when it happens if I minimize the window and click on the desktop wallpaper, the next time I fullscreen the app it behaves correctly, so it must be related to window focus.
I'm affected. I think it is in someway by apps running XWayland going full screen. The XWayland apps themselves are always able to go fullscreen just fine, but they sometimes trigger the bugged state for the native Wayland apps. Ex: open both VLC (XWayland) and a native Wayland app (Gwenview). Watch a video on VLC on full screen for some seconds... exit full screen but leave VLC open, and try to put the Wayland app on full screen: it will sometimes trigger the bug, sometimes not. If I insist on trying this recipe, it will surely trigger the bug eventually. Once triggered, the bug consistently keeps happening every time the Wayland goes full screen, but immediately stops happening when I simply minimize VLC.
If you click a fullscreen window, does it go above the panel?
(In reply to Vlad Zahorodnii from comment #7) > If you click a fullscreen window, does it go above the panel? Not in my case.
What's the visibility of the panel? is it "always visible" or something else?
(In reply to Vlad Zahorodnii from comment #9) > What's the visibility of the panel? is it "always visible" or something else? It's set as always visible. I should note I can't reproduce it every time. I tried testing it a couple of minutes ago and it worked fine, then I clicked on the browser to access this page and when I tested it once more the bar was on top of the fullscreen window (tested with Gwenview).
(In reply to Eduardo from comment #6)> > Ex: open both VLC (XWayland) and a native Wayland app (Gwenview). Watch a > video on VLC on full screen for some seconds... exit full screen but leave > VLC open, and try to put the Wayland app on full screen: it will sometimes > trigger the bug, sometimes not. I can reproduce with your steps on Plasma 5.23 beta. Operating System: Arch Linux KDE Plasma Version: 5.22.90 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Graphics Platform: Wayland
Confirmed, I was able to reproduce it.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/1481
Can somebody please verify whether !1481 fixes the issue?
More reliable steps to reproduce: * launch vlc * launch gwenview * alt-tab to vlc * alt-tab again to vlc, that's it, open task switch, cycle through windows and select vlc * alt-tab to gwenview * make gwenview fullscreen
vlc doesn't need to be fullscreen
(In reply to Vlad Zahorodnii from comment #14) > Can somebody please verify whether !1481 fixes the issue? your patch fixes the bug on neon unstable \o/
Git commit e6c77a1ddc0226e5893cc7403a5f6344032e07c2 by Vlad Zahorodnii. Committed on 05/10/2021 at 14:53. Pushed by vladz into branch 'master'. Clear should_get_focus in Workspace::focusToNull() On X11, there are four input models. With some input models, it's okay if the window manager calls XSetInputFocus(), with others, the wm has to ask the client to make a XSetInputFocus() request. If kwin wants a client to take input focus, kwin will add the client to the should_get_focus list, which contains all the windows that are about to get input focus. Clients are popped from the list upon receiving FOCUS_IN events. A client will be added to the should_get_focus list even if kwin thinks that the client already has input focus because communication between the wm and xorg is async, anything can happen with input focus in meanwhile. On the other hand, the wm may sometimes focus the null window if no window should contain the input focus. The issue is that the should_get_focus list is not cleaned up in that case, which can lead to Workspace::mostRecentlyActivatedClient() returning wrong client and possibly other async related issues. We don't have such madness on Wayland as the compositor is in charge of handling input focus. This change makes Workspace::focusToNull() clear the should_get_focus, which is reasonable. We need to deactivate "in-flight" focus requests. This also fixes the bug where fullscreen Wayland windows don't go above docks and panels due to Workspace::mostRecentlyActivatedClient() returning bad client. Related: bug 395919 M +1 -0 src/workspace.cpp https://invent.kde.org/plasma/kwin/commit/e6c77a1ddc0226e5893cc7403a5f6344032e07c2
Git commit fba3f1e7311bcd1bb7dc0113bfb16a82a656b8c7 by Vlad Zahorodnii. Committed on 05/10/2021 at 14:54. Pushed by vladz into branch 'Plasma/5.23'. Clear should_get_focus in Workspace::focusToNull() On X11, there are four input models. With some input models, it's okay if the window manager calls XSetInputFocus(), with others, the wm has to ask the client to make a XSetInputFocus() request. If kwin wants a client to take input focus, kwin will add the client to the should_get_focus list, which contains all the windows that are about to get input focus. Clients are popped from the list upon receiving FOCUS_IN events. A client will be added to the should_get_focus list even if kwin thinks that the client already has input focus because communication between the wm and xorg is async, anything can happen with input focus in meanwhile. On the other hand, the wm may sometimes focus the null window if no window should contain the input focus. The issue is that the should_get_focus list is not cleaned up in that case, which can lead to Workspace::mostRecentlyActivatedClient() returning wrong client and possibly other async related issues. We don't have such madness on Wayland as the compositor is in charge of handling input focus. This change makes Workspace::focusToNull() clear the should_get_focus, which is reasonable. We need to deactivate "in-flight" focus requests. This also fixes the bug where fullscreen Wayland windows don't go above docks and panels due to Workspace::mostRecentlyActivatedClient() returning bad client. Related: bug 395919 (cherry picked from commit e6c77a1ddc0226e5893cc7403a5f6344032e07c2) M +1 -0 src/workspace.cpp https://invent.kde.org/plasma/kwin/commit/fba3f1e7311bcd1bb7dc0113bfb16a82a656b8c7
*** Bug 414242 has been marked as a duplicate of this bug. ***
*** Bug 375759 has been marked as a duplicate of this bug. ***