Created attachment 165573 [details] Incorrect window behaviour when unmaximising on wayland SUMMARY *** Wayland apps dont preserve their size and position after being maximized, closed and reopened. This breaks my workflow since I have to remember to unmaximize app before closing it to prevent this issue from happening. It doesnt happen with applications using xwayland *** STEPS TO REPRODUCE 1. Open wayland application and maximize it 2. Close the wayland application 3. Reopen wayland application and unmaximize it OBSERVED RESULT window doesnt preserve its previous size and position EXPECTED RESULT window should preserve its previous size and position SOFTWARE/OS VERSIONS Linux/KDE Plasma: tested on arch, debian 12, neon unstable (plasma 6), kubuntu 24.04, all have the same issue KDE Plasma Version: 5.27.* and 6.0 KDE Frameworks Version: idk Qt Version: 5,6 ADDITIONAL INFORMATION I hope this is not a duplicate issue, since I cant find anything similar on this bug tracker or any other bugtracker, this issue persists on very different hardware (nvidia laptops, old thinkpads, desktops with amd dgpus, virtual mashines even)
I can reproduce this, but only on a fresh user account. On my main account it works as it should. Not sure why. Operating System: KDE neon Testing Edition KDE Plasma Version: 6.0.0 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.1 Kernel Version: 6.5.0-15-generic (64-bit) Graphics Platform: Wayland Graphics Processor: AMD Radeon Pro WX 3200 Series
Sorry, forgot to add that I tried a fresh user account because it looks like that what you have there. Do you have issues with this bug as you go further with the set up of your account?
Yes, this bug was here with me since May of last year (I reinstalled arch then and version was 5.27 and I thnk bug was there since the beginning)
I thought that the client is responsible for this under wayland?
In both X11 and Wayland, the window is responsible for preserving its size. On X11 it's also responsible for preserving its position, while on Wayland the window is not able to do this so currently the feature does not exist. In all cases, bugs in the window manager can also affect this. I can reproduce the issue with Dolphin, Gwenview, and other KXMLGui-using apps. It may be an issue in KXMLGui somewhere, or it might be an issue in KWin. Will investigate.
I can reproduce this issue with every wayland app I tried (firefox, dolphin, gwenview, vlc, thunderbird forced to use wayland via env variable (in xwayland it works as intended), webcord, brave,...) Also I didnt know compositor cant force position on specific window in wayland (I thought apps just had no way to tell compositor where they want to be placed, but compositor was free to put them wherever he wants) And also this issue isnt present in gnome from what I saw, but it is with gnome apps on kde (video trimmer for example)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5145
Git commit e974c07001a34f006bbf3e730de42dfc417db2a4 by Vlad Zahorodnii. Committed on 08/02/2024 at 14:46. Pushed by vladz into branch 'master'. wayland: Schedule a configure event when borders change Window::checkWorkspacePosition() before the window is mapped is still problematic and should be avoided as it can produce undesired constrained client size (1x1). Given that XdgToplevelWindow tries to maintain the same frame geometry size, it should be enough to schedule another configure event instead. It is going to be in line with the other decoration logic in the XdgToplevelWindow and it's a better way to handle async geometry updates. M +2 -8 src/window.cpp M +10 -0 src/x11window.cpp M +6 -0 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/-/commit/e974c07001a34f006bbf3e730de42dfc417db2a4
Git commit 89688db8e9e6b321afde9adb4f9397cab6af3346 by Vlad Zahorodnii. Committed on 08/02/2024 at 15:14. Pushed by vladz into branch 'Plasma/6.0'. wayland: Schedule a configure event when borders change Window::checkWorkspacePosition() before the window is mapped is still problematic and should be avoided as it can produce undesired constrained client size (1x1). Given that XdgToplevelWindow tries to maintain the same frame geometry size, it should be enough to schedule another configure event instead. It is going to be in line with the other decoration logic in the XdgToplevelWindow and it's a better way to handle async geometry updates. (cherry picked from commit e974c07001a34f006bbf3e730de42dfc417db2a4) M +2 -8 src/window.cpp M +10 -0 src/x11window.cpp M +6 -0 src/xdgshellwindow.cpp https://invent.kde.org/plasma/kwin/-/commit/89688db8e9e6b321afde9adb4f9397cab6af3346