Bug 470318 - Wayland: window positioning lost on application restart
Summary: Wayland: window positioning lost on application restart
Status: RESOLVED DUPLICATE of bug 15329
Alias: None
Product: plasmashell
Classification: Plasma
Component: general (show other bugs)
Version: 5.27.4
Platform: Fedora RPMs Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-05-26 23:27 UTC by Raman Gupta
Modified: 2023-05-31 19:53 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Raman Gupta 2023-05-26 23:27:50 UTC
SUMMARY

In Wayland, when an application starts, it always starts in the middle of the center monitor, regardless of where it was positioned when it was shut down.

This is most annoying for applications for which users routinely have multiple positions opened, carefully positioned. This includes browsers like Firefox and Chrome, and IDEs and editors like Kate and IntelliJ IDEA.

This is not an issue in X11. Applications always start up with the same monitor positioning, and window size/positioning 

STEPS TO REPRODUCE
1. In a Wayland session, start Firefox (configure Firefox to re-open previous Windows and tabs on restart)
2. Move a window to the left (or open multiple windows, and  move them around the scrreen and resize them)
3. Shut down Firefox
4. Restart Firefox

Same goes for Chrome or IntelliJ IDEA or Dolphin or anything else.

OBSERVED RESULT

The Firefox window, or windows, are all positioned at the center of the primary screen.

EXPECTED RESULT

The Firefox windows should all open up at their previous positions, and on the same screens they were on when Firefox was shut down.

SOFTWARE/OS VERSIONS
Operating System: Fedora Linux 38
KDE Plasma Version: 5.27.4
KDE Frameworks Version: 5.104.0
Qt Version: 5.15.8
Kernel Version: 6.2.9-300.fc38.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 2 × 12th Gen Intel® Core™ i9-12900KS
Memory: 3.8 GiB of RAM
Graphics Processor: llvmpipe
Manufacturer: QEMU
Product Name: Standard PC (Q35 + ICH9, 2009)
System Version: pc-q35-7.2

ADDITIONAL INFORMATION

I've tested this on my own box with AMD graphics hardware, as well as on a QEMU virtual machine using llvmpipe, and its the same behavior. Virtual machine info given above.
Comment 1 Nate Graham 2023-05-31 19:08:13 UTC
The TL;DR version is that this will become a reality once all windows are native Wayland windows and Bug 15329 is implemented in KWin.

If you'd like more details, read on. The way window placement works is as follows:

On X11
======
Per the X11 spec, windows are  allowed to place themselves on the screen--but they aren't required to. If a window doesn't, then KWin places it according to its placement policy, which is user-controllable. This includes XWayland apps run in a Wayland session.

KWin *could* in theory ignore this and forcibly place X11 windows according to its placement policy. But doing so unconditionally would not only break the spec, but in practice it would also break apps that were developed with the expectation of being able to place their own windows whatever they want, so instead this is an opt-in thing that you as the user have to turn on via the Window Rules system.

Because that would be annoying, many X11 apps implement their own "remember my window positions" feature. And many--but not all--KDE apps do so on X11. In QtWidgets apps that use KDE's KXMLGui framework for the main window, it's a standard feature that apps' main windows get automatically, and whether or not to do it is controlled by the "Allow apps to remember the positions of their own windows, if they support it" checkbox that's on the "Advanced" page of the Window Behavior KCM.

For Kirigami-using apps, there is no central automatic thing for it as with KXMLGui because Kirigami is a tier 1 framework and therefore cannot depend on KConfig, and it would need to do so to be able to write the necessary data into the app's config file. As a result, Kirigami-based apps often implement this logic themselves in a custom way. A way to improve the status quo would be to write a standard "WindowStateSaver" object (or whatever) that lived in like Kirigami-addons or something and contained the window state saving  logic in a central place, and then Kirigami apps that want to use it could opt into it by importing kirigami-addons and adding that object to their windows as needed.

So yes, as you can see, this is a mess. :) On Wayland it's much simpler:

On Wayland
==========
Native wayland windows are not allowed to determine where to place themselves on screen at all, and as a result, app windows always respect KWin's placement policy. So KWin itself would have to gain a "remember window positions" feature, but then once it did, it would apply to all native Wayland windows. This is tracked in Bug 15329.

*** This bug has been marked as a duplicate of bug 15329 ***
Comment 2 Raman Gupta 2023-05-31 19:53:23 UTC
(In reply to Nate Graham from comment #1)
> Per the X11 spec, windows are  allowed to place themselves on the screen--but 
> they aren't required to. If a window doesn't, then KWin places it according to its
> placement policy, which is user-controllable. This includes XWayland apps run 
> in a Wayland session.

I've experimented with `MOZ_DISABLE_WAYLAND=1 firefox` and indeed the window positioning appears to be saved and restored when Firefox is run via XWayland.

Thanks for the detailed explanation.