SUMMARY Since the height is too high, the bottom of the window is hidden behind panel or edge of the screen. STEPS TO REPRODUCE 1. Open any GTK app (was tested with FF in Wayland mode), it must be maximized on start. OBSERVED RESULT Bottom of the app window is below visible desktop area. EXPECTED RESULT All window content should be visible. If there is bottom panel and it's Visibility Setting set to "Always Visible", it shouldn't hide the window. SOFTWARE/OS VERSIONS Operating System: Fedora 33 KDE Plasma Version: 5.21.80 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Especially annoying when the hidden area contains sensitive data, e.g Search field in FF.
Created attachment 135315 [details] debug firefox-wayland with window hidden by bottom panel
Also seen on X11 (Bug 432096), so maybe this isn't a Wayland-specific issue?
Oh also the app in question for that bug report (Scribus) is Qt-based, not GTK-based.
(In reply to Nate Graham from comment #2) > Also seen on X11 (Bug 432096), so maybe this isn't a Wayland-specific issue? Hm, the symptoms for the Qt-based/X11 app look the same, but still this one probably Wayland-specific bug because I can't reproduce it for FF on XWayland (but didn't try it on X11). Someone with more specific experience should review, though.
Workaround: press Restore button of window's header, and then maximize it again.
This is weird 3725.368] -> xdg_toplevel@54.set_maximized() [673725.408] -> wl_surface@37.commit() [673725.425] -> org_kde_kwin_server_decoration_manager@17.create(new id org_kde_kwin_server_decoration@55, wl_surface@37) [673725.464] -> org_kde_kwin_server_decoration@55.request_mode(2) We're seeing a commit after we're requested a maximise, but before we've set we're using CSD. It's only when we attach a buffer that we do the next commit. At which point at least our first frame will be in the wrong place. Whilst we should handle this case, it's also a sign of something off client-side.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/699
It seems was also reported recently on Mozilla bugtracker: https://bugzilla.mozilla.org/show_bug.cgi?id=1702853
Git commit ab58171ed857daf842e54f487d37ab4855260061 by Nate Graham, on behalf of Vlad Zahorodnii. Committed on 07/04/2021 at 20:38. Pushed by ngraham into branch 'master'. wayland: Check workspace position after creating decoration If a decoration is created for an already mapped maximized window, check the workspace position to ensure that the window still fits the maximize area. M +0 -1 autotests/integration/xdgshellclient_test.cpp M +5 -2 src/xdgshellclient.cpp https://invent.kde.org/plasma/kwin/commit/ab58171ed857daf842e54f487d37ab4855260061
Git commit e7d53f0848498958aa8dccf3bb515283ba07a5f8 by Nate Graham, on behalf of Vlad Zahorodnii. Committed on 07/04/2021 at 20:44. Pushed by ngraham into branch 'Plasma/5.21'. wayland: Check workspace position after creating decoration If a decoration is created for an already mapped maximized window, check the workspace position to ensure that the window still fits the maximize area. (cherry picked from commit ab58171ed857daf842e54f487d37ab4855260061) M +0 -1 autotests/integration/xdgshellclient_test.cpp M +5 -2 xdgshellclient.cpp https://invent.kde.org/plasma/kwin/commit/e7d53f0848498958aa8dccf3bb515283ba07a5f8
Interestingly the same problem was found on Gnome: https://bugzilla.mozilla.org/show_bug.cgi?id=1702853#c4 Does it mean it's actually a GTK problem or something?
*** Bug 425276 has been marked as a duplicate of this bug. ***