| Summary: | GTK apps maximized on start are too high - bottom of the window is not seen | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Andrey <butirsky> |
| Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | kde, kirill.bogdanenko, nate |
| Priority: | NOR | Flags: | butirsky:
Wayland+
|
| Version: | git master | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| URL: | https://bugzilla.mozilla.org/show_bug.cgi?id=1702853 | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=432253 https://bugs.kde.org/show_bug.cgi?id=432096 |
||
| Latest Commit: | https://invent.kde.org/plasma/kwin/commit/e7d53f0848498958aa8dccf3bb515283ba07a5f8 | Version Fixed In: | 5.21.5 |
| Sentry Crash Report: | |||
| Attachments: | debug firefox-wayland with window hidden by bottom panel | ||
|
Description
Andrey
2021-01-30 23:05:02 UTC
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. *** |