Bug 503446 - Positioning of windows in restored session doesn't work (Wayland session restore new protocol)
Summary: Positioning of windows in restored session doesn't work (Wayland session rest...
Status: RESOLVED DUPLICATE of bug 15329
Alias: None
Product: kwin
Classification: Plasma
Component: general (other bugs)
Version First Reported In: master
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: qt6, wayland-only
Depends on:
Blocks:
 
Reported: 2025-04-27 21:24 UTC by Piotr Mierzwinski
Modified: 2025-05-21 20:49 UTC (History)
3 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 Piotr Mierzwinski 2025-04-27 21:24:51 UTC
SUMMARY
Couple weeks ago Nate announced "KWin has gained support for the initial version of the Wayland session restore protocol" which among others provides: "support window sizing, positioning". Seems changes already reached Neon distribution, because sizing seems work. Unfortunately positioning doesn't.
My configuration is as following:
A laptop is connected via HDMI with external monitor whereas built-in display turned off (the lid is closed). I have neither no virtual desktops nor activities.

STEPS TO REPRODUCE
1. Turn on in System Setting "Session restore"  (checked option "On last logout")
2. start couple applications (I have 3 Firefox window,1 dolphin, 1 kate, 1 konsole)
3. restart PC or turn off and on again

OBSERVED RESULT
Size of windows is restored correctly, but their position are not restored - all are stack in the center of the screen

EXPECTED RESULT
Size and position of windows should be restored correctly

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
KDE Plasma Version: 6.3.80
KDE Frameworks Version: 6.14.0
Qt Version: 6.8.3

ADDITIONAL INFORMATION
Wayland, Neon
Comment 1 Lenzoid 2025-04-27 23:58:56 UTC
Can confirm this on git-master, Arch Linux, amdgpu, Laptop with external screen via HDMI and internal screen enabled. The restored windows spawn on the external monitor, all centered.
Comment 2 Zamundaaa 2025-04-28 13:18:15 UTC
Apps still need to support it
Comment 3 Piotr Mierzwinski 2025-05-01 21:02:03 UTC
(In reply to Zamundaaa from comment #2)
> Apps still need to support it
So for every KDE apps needs to be added support for this feature? If so, then how this will work for non KDE apps, like Firefox?

Saving size of windows works, but saving position doesn't. IMHO Nate's announcement was very misleading or not very precise, at least for me.
Comment 4 Lenzoid 2025-05-01 22:38:34 UTC
Hi Piotr, thanks for taking the time and testing this out on such a recent system like Neon. That's really cool. I'm by no means an expert on this, but it seems that this is just one of the messy things inherited from the X11 era, where windows could place themselves and many making their own implementations on how they remember position.

Nate has written an explanation about this, giving some background about how positioning windows is different in X11 than in Wayland:

"Native Wayland windows are not allowed to determine where to place themselves on screen at all; the compositor does this."

https://invent.kde.org/ngraham/canned-responses#user-reports-that-wayland-app-doesnt-remember-its-window-position-observes-that-it-works-on-x11-for-them-and-requests-an-explanation-of-why-theres-a-difference

From my first tests, a possible solution (not remembering per se but an initial positioning on session start) for us users could be System Settings > Window Management > Window Rules > Add new... > Detect Window Properties and click the window which position you wish to be enforced. Click the Plus and check mark buttons on Window class, Position, Size etc. Haven't tried this for Firefox windows but I imagine it's difficult identifying your three different windows. Maybe this helps you, it did for me.

*** This bug has been marked as a duplicate of bug 15329 ***
Comment 5 Piotr Mierzwinski 2025-05-04 00:42:45 UTC
(In reply to Lenzoid from comment #4)
> Hi Piotr, thanks for taking the time and testing this out on such a recent
> system like Neon. That's really cool. I'm by no means an expert on this, but
> it seems that this is just one of the messy things inherited from the X11
> era, where windows could place themselves and many making their own
> implementations on how they remember position.
> 
> Nate has written an explanation about this, giving some background about how
> positioning windows is different in X11 than in Wayland:
> 
> "Native Wayland windows are not allowed to determine where to place
> themselves on screen at all; the compositor does this."
> 
> https://invent.kde.org/ngraham/canned-responses#user-reports-that-wayland-
> app-doesnt-remember-its-window-position-observes-that-it-works-on-x11-for-
> them-and-requests-an-explanation-of-why-theres-a-difference
> 
> From my first tests, a possible solution (not remembering per se but an
> initial positioning on session start) for us users could be System Settings
> > Window Management > Window Rules > Add new... > Detect Window Properties
> and click the window which position you wish to be enforced. Click the Plus
> and check mark buttons on Window class, Position, Size etc. Haven't tried
> this for Firefox windows but I imagine it's difficult identifying your three
> different windows. Maybe this helps you, it did for me.
> 
> *** This bug has been marked as a duplicate of bug 15329 ***

Thank you for work around. I will test it.
Your previous answer "Apps still need to support it" means that the support will be provided in the future (maybe in Plasma 6.4 yet)?
Anyway I hope so, because now we have regression compare to Plasma 5 or Plasma 6 and X11 session and soon we will have 6.4 version...

[Nate] "Native Wayland windows are not allowed to determine where to place themselves on screen at all; the compositor does this."
I'm confused a bit. Firstly you said that applications need to support it, and Nate saying that "the compositor does this.". So how exactly is?
I found that doesn''t it (windows position seem isn't save) and reported it, because I supposed that "the compositor does this."
Comment 6 Zamundaaa 2025-05-05 17:42:56 UTC
(In reply to Piotr Mierzwinski from comment #5)
> Your previous answer "Apps still need to support it" means that the support
> will be provided in the future (maybe in Plasma 6.4 yet)?
For KDE apps, yes. There is an implementation in Qt, though I don't know in which version it'll land.

> [Nate] "Native Wayland windows are not allowed to determine where to place
> themselves on screen at all; the compositor does this."
> I'm confused a bit. Firstly you said that applications need to support it,
> and Nate saying that "the compositor does this.". So how exactly is?
> I found that doesn''t it (windows position seem isn't save) and reported it,
> because I supposed that "the compositor does this."
The compositor has control over window positioning, but applications still need to provide information about which window corresponds to which window of the previous session.
Comment 7 Piotr Mierzwinski 2025-05-21 20:49:18 UTC
> The compositor has control over window positioning, but applications still need to provide information about which window corresponds to > which window of the previous session.

So how this will be solved in non KDE application, i.e. Firefox?
They (applications) will be patched by persons making packages for given distribution? 
Or maybe such application will positioned at central of screen, like now is happen for all?