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

[Duncan]

René J.V. Bertin posted on Wed, 29 Apr 2026 15:34:28 +0200 as excerpted:

> On Tuesday April 28 2026 13:51:34 Duncan wrote:
> 
>>> I thought this was a pure Firefox bug, but it doesn't happen when I
>>> run Xfwm4 (under a KDE environment).
>>> 
>>> I've now seen it in KWin4 and KWin5 5.15.5 and whatever (quite) newer
>>> version is in Devuan Chimaera.
>>> 
>>> It only happens though after I exited the browser properly, not after
>>> an unexpected exit.
> 
> Wow, as usual with your replies, it's a real question where to begin to
> answer! :)

LOL.  Can't disagree. =:^)  And of course my being Autism Spectrum doesn't 
help, as that means I pull in all sorts of only (to neurotypicals) 
remotely/tangentially related bits that /could/ actually end up being 
relevant to the corner-cases that most of the bugs you and I as "advanced" 
users typically post about here.

[Note as I'm about to send.  I really hope this is at least of /some/ 
help.  FWIW it'd probably be the part after the last quoted section if so 
as that most directly addresses your problem at hand.  Because I spent 
/wayy/ too many hours writing and rewriting this.  Of course I try to 
justify it by saying I enhanced my own understanding in the writing, and 
that's true as far as it goes, and I accept that this is classic spectrum 
behavior and that's true too, but it's still unjustifiably long even given 
both of those, so I really hope you get /something/ useful out of it too!]

> Re: libglvnd : I don't even have that installed.

Libglvnd is an interesting library.  What it does is in the name: it 
provides a vendor-neutral (the vnd) OpenGL (the gl) dispatch layer (I was 
going to say abstraction, but looking it up dispatch layer is the more 
accurate term they use) that allows multiple opengl implementations to 
exist on the same system.  It intercepts opengl calls and routes them to 
the on-system implementation it deems appropriate.

In theory it shouldn't be (and isn't) necessary for systems with only a 
single opengl implementation installed (here, mesa), but in addition to 
the choice-of-dispatch functionality it offers, for distros it 
conveniently allows simplifying their OpenGL package dependency logic by 
having most gl/gles reverse-deps depend on libglvnd alone, then having 
libglvnd as a single package location to deal with the OR deps that would 
otherwise have to be duplicated into perhaps hundreds of different gl/
gles-dependent packages.

Back when I experienced the libglvnd (kwin-)aurorae-engine-based windeco 
bug I mentioned, apparently at least one critical OpenGL call the aurorae 
engine made wasn't properly intermediated by libglvnd with only mesa as an 
on-system OpenGL provider (on amdgpu at least), such that while nothing 
crashed (libglvnd apparently took the call correctly, it just did nothing 
with it instead of routing it to mesa), the decoration simply wasn't 
drawn, thereby making it entirely invisible while still responsive to 
clicks on the invisible buttons if one knew where to click, etc.

As that was when Gentoo was just switching to mandatory libglvnd to 
simplify its other OpenGL dependencies, at first I just reverted that 
freshly introduced mandatory depend to keep it off the system and just let 
mesa handle it as it always did... and as a temporary measure that did 
work.  Eventually I could revert my revert and let libglvnd be installed 
because I was no longer using an aurorae-engine-based windeco (so I never 
did really know if/when that invisible-aurorae-based-windeco bug was 
fixed), having switched back to (ultimately my patched) oxygen as windeco.

But that's why you don't have libglvnd installed -- apparently the devuan 
I see you use hasn't done that opengl dependency simplification, and is 
still pulling in its dependencies directly.  (Actually, assuming the 
freedomware policy remains debian-alike that makes sense, as to my 
knowledge mesa's really the only freedomware choice as opengl provider, 
which would make libglvnd an additional layer without a reason that can be 
justified within the freedomware policy.  Gentoo's a bit different in that 
regard since while binaries for most packages are now available, 
primarily, it simply provides automated dependency resolution and 
buildscripts, and while the distro is forbidden by policy from /relying/ 
on non-freedomware, the policy and thus it would seem the devs as a whole 
don't seem to have a problem with making it easier to use with packages 
such as libglvnd that lack a freedomware-only purpose.)

Of course now full gl has been quite legacy for some time and gles less so 
but still legacy relative to vulkan, the newer 3D-rendering kid on the 
block along with wayland (with X and its gl both legacy).  And to the 
degree that gl /is/ legacy, demand for it and thus reverse-depends on it 
are decreasing over time, and with that of course the relevancy of  
libglvnd.  In another five years it's likely to be quite solidly legacy, 
and in a decade, effectively of historical interest only.  (Tho of course 
that hits rather differently when I know I'm addressing someone who still 
has an active kde4 interest...)

> Re: windecos in KWin: in KWin4 I use the one from QtCurve. That was
> sadly never ported to KF5 so with KWin5 I use the Oxygen deco there.
> With small buttons and a 10pt titlebar font (@86DPI) I get titlebars
> that are compact enough even on a 1366x768 LCD panel.

IIRC qtcurve was an effort at a gtk/gnome/qt/kde unified theme.  It seems 
the newest effort in that regard is union, according to the kde git logs 
I've been reading.  I'm not updating quite as frequently due to other 
projects ATM, but last I read the plasma folks were only getting started 
on integration, with the intent to make it so qtwidget (C++) and qtquick/
qtscript apps had a more common theme/look than possible with qt/kde/
plasma5 and 6 to this point.  There seem to be multiple elements to it 
much as there was with oxygen in the kde4 era and breeze in plasma5 and 
current plasma6.  I was under the impression that it was to unify theming 
with gtk apps too, but as I'm writing this I realize I can't claim to know 
that for sure and I may have just gotten that impression from the language 
in the git logs around the qt-scripted vs. qtwidget theming unification.  
But I /think/ it's supposed to be gtk too.

Regardless, if it ends up like qtcurve or the plasma5 default breeze, it's 
not going to appeal much to me.  But there *is* some recent development 
activity around reinvigorating/modernizing oxygen (some of the original 
functionality had bitrotted over the years or in the qt/kf6 port, not to 
crash levels but things like missing transparency in some cases, etc, that 
the refresh is bringing back), so hopefully they'll continue to support 
what will be second-back oxygen along with first-back breeze, along with 
the new union, for another qt/kf/plasma generation or two.

Meanwhile, to explain why titlebar height is such a big deal to me, 
despite my three 50-inch/127cm 4K TVs as monitors.  Two points: First, a 
bigger desktop generally means more windows displayed at once, which means 
more titlebars, which if they're unnecessarily tall, means more wasted 
space, in the absolute if not in percentage.

Second, ultimately, if I'm keeping both app text and titlebar text 
readable without unnecessary padding, a titlebar takes roughly the same 
vertical space as a line of text, so the titlebar is effectively replacing 
a would-be line of app-text that I now can't display because of that 
titlebar.  That's one less line of web-page, one less line of terminal 
text, one less line of an email message or one less message listed in the 
message-list, etc.  And that's if the titlebar is as vertically space-
efficient as possible.  If that titlebar has unnecessary vertical padding, 
that's *two* less lines of app-text displayed instead of one, *two* less 
lines of message displayed, *two* less lines of terminal height.  And 
while the tradeoffs for the loss of *one* such line for a titlebar are 
arguably reasonable -- there are benefits to a visible/readable titlebar 
after all -- I do *not* find it reasonable to have to lose *two* lines of 
app-text for *one* line of titlebar, entirely unnecessarily because of 
some (IMO) "useless" padding someone thought looked nice... without IMO 
giving proper consideration to the efficiency cost of the app-text line 
lost as a result!


> I see I didn't mention it but the issue occurs for me under Wayland too
> (the KF5 install in Devuan Chimaera is recent enough to provide a stable
> Wayland environment). On a side-note: with KWin5's continued support for
> decoration themes I think we must be talking about server-side
> decorations anyway (hooks in the platform plugin to theme CSD would only
> work for Qt-based applications).

Yes, KDE/plasma/kwin definitely still has server-side windecos on 
wayland.  In fact, that was one of the formative debates in early wayland 
history, with the gnome folks initially assuming wayland was going to be 
their opportunity to go client-side-decorations only once and for all, and 
the kde/kwin folks staking out an absolute position that X or wayland, 
they were sticking with server-side decorations, backing it up with their 
technical reasons why server-side was better and insisting on it for kde, 
and maintaining it as an option for wayland. (There's a well known blog 
post where the then kwin lead developer stakes out that position and gives 
his reasons.)

Once the gnome/client-side folks saw kde/kwin was insisting on server-
side, and that it was an absolute position to the point that kde would 
very possibly fork the wayland protocol if that's what it took to keep 
server-side, they relented, and the wayland protocol ended up allowing 
either one.  I'm not sure of the technical details at the protocol level, 
but from what I've seen as a user who regularly follows kwin (among other) 
git logs and from ordinary usage, I'd take it to be an option in the 
protocol now, with both major toolkits (gtk/qt) supporting both, apps 
built on them supporting both by virtue of the toolkit, and the running 
wayland compositor then setting the default for the session.  With  
support in both toolkits, qt/kde apps can do client-side windecos if they 
are running on a compositor where that's the default, and gnome/gtk apps 
can omit drawing their normal client-side decos if they're running on a 
default-server-side-deco compositor.  (And FWIW there's libdecor too, a 
toolkit-independent clientside windecos library for wayland clients.  A 
quick deps query here says mesa-tools and sdl2 are its only installed 
reverse-deps here, and I've way more gtk than that on a kde/plasma 
desktop, so it doesn't seem /too/ popular, but it's there.)

(Too, I have weston installed as a backup wayland compositor (which I 
figure is wise to have because I am after all running live-git kwin, and 
which is vastly simpler in config and dependency terms than trying to keep 
xorg functioning as a backup, and thus much more likely to actually work 
if I need it, but I've not had to use it in years now).  Weston ships its 
own terminal app, weston-terminal, quite usefully so given its rudimentary 
menu or other launching support so launching weston-terminal and then 
launching everything else from it is the workflow I found easiest.  
Anyway, and it was quite informative to compare weston-terminal running on 
kde/kwin/plasma-wayland to weston-terminal running on weston, to konsole 
running on weston, to konsole running on plasma/kwin-wayland.  FWIW 
weston-terminal, unlike gtk-based apps, still has its client-side windeco 
even when run on kwin_wayland, and it's very obvious as it sticks out like 
a sore thumb!  kwin obviously can tell it has client-side decos and 
doesn't add server-side by default, but an interesting exercise I just 
tried was forcing kwin/plasma's normal server-side via kwin window rule 
forcing the titlebar/border on.  Then it has both, the weston-terminal 
client-side windeco appearing inside the kwin window-rule-forced normal 
kwin/plasma servers-side windeco!  It's not particularly /functional/ to 
have both, and of course I use konsole by default in any case, but seeing 
both on the same app at the same time is useful from an educational 
perspective.)

> But the crucial point here is that it is really something specific to
> Firefox's session restore feature, and only when it's allowed to do its
> work properly (or the way it thinks proper).
> 
> It looks like something in the code gets executed when doing a proper
> "quit" updates the actual positions and sizes of the windows that are to
> be restored, and makes an error. Prevent that code from being executed
> by killing the application and windows do return to their expected
> positions and sizes.

Hmm.  Emphasis on the session-restore now, but such that killing allows 
firefox to return to normal size while quitting, thus allowing settings to 
save, has it doing the shrink-by-titlebar-size thing.

But I think you're incorrect in specifying *firefox*'s session restore, 
since my experience is that firefox's session restore handles getting back 
the webpages that were running when it crashed, etc, and that it actually 
does that impressively well at a crash, but that it doesn't handle window 
size, etc (tho that's very likely due to my kwin window rules that handle 
firefox window size).  Rather, I think you were correct in your first post 
when you said you had thought it a firefox bug, but that it doesn't happen 
under xfc4wm (on an otherwise kde environment), so you're now doubting 
that.

IOW, I think it's *kwin's* bug, very likely either the same one I 
experienced back in the day (tho the details of my experience differed but 
the titlebar size difference was the same for both you and I), or another 
related to it, likely with the same root cause.

While your bug seems to be occurring on both X and wayland, it's worth 
noting that kde's wayland session restore (of the desktop session not just 
individual applications) has only recently become a thing, and that in the 
process they've dealt with bugs in the previously X-only session restore 
as well.  But that's /quite/ recently, as in, plasma6 this year recently, 
and while you've mentioned upgrading kde4 to now 5, I've seen nothing 
about 6 and certainly not this-year-recent 6.  So I'm guessing you're 
running into kde/kwin/plasma bugs that have been there for awhile and may 
only have been fixed in this-year-recent kde/plasma6, **IF** it's actually 
session-restore.

But, what I /actually/ think is that it's not /session/ restore so much as 
a different feature that's usually seen in app-(re)launch context but is 
/not/ session-restore, but rather something else...

More precisely, I think it's the behavior that's usually automatic but 
that can be configured in an toggle-on/off fashion for two slightly 
different behaviors, via kde window rules, that being ignore requested 
geometry, and obey geometry restrictions.

Now it used to confuse me what the actual difference was, but somewhere 
aling the line kde/kwin added info icons that upon hover popup 
explanations.  It turns out "geometry restrictions" refers to more 
special-case situations like only expanding a window by a number of pixels 
that corresponds to the height of a text line, for instance, or like 
honoring the width/height ratio (as opposed to specific size) of images 
and video when opening them specifically.  So that rule controls whether 
kwin responds to those special-case requests made when the window is 
opened, say konsole requesting that the window size (at launch and at 
resize) correspond to one that will show a specific number of lines (and 
possibly columns), not lines and a half-line.  If this restriction is 
honored for konsole, resizing the konsole window will be "jumpy" compared 
to resizing it a pixel at a time, since a displayed character will be 
several pixels high and several pixels wide, and the request is to only 
resize accordingly.

Meanwhile, "requested geometry" is the more general case, the actual size 
of the requested window, and I believe that as with my bug several years 
ago (that could well be with the same code you're only now running, since 
I'm on live-git and you're barely upgrading to kde5 and nowhere near 6 let 
alone current 6), the bug is very likely in this feature and code, 
specifically, a bug in how kwin calculates what it thinks is client-side 
vs. server-side windeco titlebar height, and allows for it when it records 
window size on a quitting app, vs recalling and applying that size on a 
freshly started app.  If the window crashes or is killed (-9/sigkill 
kernel-kill with no time to store changed config or settings), firefox (or 
kwin, not sure which) has no time to save the current window size as it 
goes down, so it restores fine.  But if the app quits normally, that size 
gets saved, and while it's saved with one assumption regarding client-side 
vs server-side decorations, with the relaunch those are applied 
incorrectly, thus resulting in a window height off by exactly the size of 
the server-side titlebar.

So play with setting ignore requested geometry and see if that changes the 
result at all.  Try playing with obey geometry restrictions too altho 
(with the additional inforation I know now) I believe that's less likely 
to be of help.  If that doesn't seem to be helping try playing with 
minimum size and size, initial and force (obviously force size as a last 
resort as that severely limits flexibility).  As a caveat, in my 
experience back then, I tried playing with them too and initially it 
didn't seem to help.  But I know a bit more now about those options so 
might have better luck now.  And eventually, I don't know /what/ fixed it, 
something I did to my config or something in a kde update, but at some 
point it /did/ stop happening.

Meanwhile, for me it was happening with other gtk-based apps (pan for 
nntp/news and claws-mail for email and as a feed-reader in particular) 
too.  But my configuration was such that I'd generally only notice it on 
apps that I had set to the height of the monitor (where if it's suddenly 
monitor-height minus titlebar height and there's another app set similarly 
underneath it, with the titlebar almost appearing to be that of the 
misbehaving app except the label is wrong, the short height and that the 
missing height is exactly titlebar height becomes very obvious), and those 
were the gtk apps in question, so that's where I noticed it.

What I'm saying is check to see if other gtk apps have the exact same too-
short-by-titlebar-height behavior.  If they do, it's almost certainly the 
same bug I had.  But if other gtk apps are fine and it's only firefox 
misbehaving, maybe it /is/ either a firefox bug, or at least, a 
misunderstanding between firefox specifically, and kwin.

-- 
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