KWin causing Firefox windows to be downsized upon restart with session restore

[Duncan]

René J.V. Bertin posted on Wed, 06 May 2026 13:17:41 +0200 as excerpted:

> René J.V. Bertin wrote on 20260504::18:32:12 re: "Re: KWin causing
> Firefox windows to be downsized upon restart with session restore"
> 
> 
>>>different behaviors, via kde window rules, that being ignore requested
>>>geometry, and obey geometry restrictions.
> 
> I tested the effect of ignoring the requested geometry. It looks like
> that could actually work if it didn't also cause windows to be restored
> at seemingly random locations, which may not even ensure that the window
> can fit on the screen without downsizing. (If that is indeed the case,
> I'd consider it a bug in KWin.)


With window rules, if ignore requested geometry needs set, it's /normally/ 
due to setting size or position, tho that isn't necessarily the case here.

So one solution to the random locations side effect might be setting 
position -- hopefully apply initially (not force) is enough so you can 
still move the window.

Alternatively, depending on your setup, setting initial placement, force, 
<as appropriate>, might work.  Setting it to on main window should at 
least eliminate off-screen placement.  (Since that's just adjusting kwin's 
default placement strategy for that window it doesn't affect later 
movement so force is fine.)

Tho I don't know why ignore requested geometry would effectively randomize 
location unless the default placement strategy is set either random or 
none, since /in/ /theory/ placement and size (and possibly maximize/
minimize) is all ignore requested geometry should affect, and for 
placement the effect should be simply to default to the default placement.

(And FWIW, default placement is, at least on my currently a bit behind 
live 6.x), set in plasma systemsettings under apps & windows, window 
management, advanced tab, window placement.  Here I have "minimal 
overlapping" selected, and the general placement works reasonably, tho 
occasionally it doesn't do /quite/ what I expect but then if I think about 
it the choice usually makes sense given the policy.  Tho FWIW based on my 
observation there was a recent slight tweak and it doesn't /always/ 
position into the largest open area like it used to.  I suspect that's 
actually due to the quite recent (this year) session-restore changes as 
kwin's now remembering better where a window was previously (keeping in 
mind that on wayland window position on the desktop is the compositor's 
job and wayland apps don't normally even know where they were so can't 
remember it for later restore... that's the compositor's job!).  But I 
haven't tracked it definitely enough to be sure.  The practical effect has 
been mixed, certainly a bit less consistent/as-expected for those (like 
me) used to the previous behavior, but not noticeably requiring more 
subsequent repositioning, as sometimes the largest open area is my highest 
priority area, just cleared due to closing a window as I shift task focus, 
and what I just opened will be a secondary window (as it was last time) so 
shouldn't be in the primary space unless I move it there anyway.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman