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
