SUMMARY When using Mozilla Firefox (Env var MOZ_ENABLE_WAYLAND=1) on Wayland, setting the window rule "No Titlebar and Frame" causes the kwin_wayland process to leak substantial memory, reaching multiple gigabytes in minutes, rapidly destabilizing the system and eventually causing a crash. Other applications (E.g. Chrome and VSCode) do not trigger this effect when identically configured. Only Firefox exhibits this issue. I would report this to Mozilla, but it's the kwin_wayland process that's inflating, looks like a safeguard is needed. Reason for applying this effect: This - combined with "Hide Titlebar" in the Breeze deco will force CSD-driven applications to use the systems native frame, even rounding bottom corners reliably! STEPS TO REPRODUCE 1. Open Mozilla Firefox 2. Open Window Rules 3. Create a new window rule targeting Firefox. 4. Add "No Titlebar and Frame", and set it to "No". You may either "Force" apply it, or set it to "Apply Initially" and restart Firefox. OBSERVED RESULT After a few seconds, the kwin_wayland process will begin rapidly consuming RAM until KWin destabilizes and crashes. If Firefox is closed, memory usage stabilizes. If re-opened, it begins climbing again. EXPECTED RESULT kwin_wayland will maintain usual RAM usage. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon KDE Plasma Version: 6.6.1 - 6.6.4 (multiple machines) KDE Frameworks Version: 6.24.0 Qt Version: 6.10.2
I only tested this on git master, but I didn't see any excessive amount of memory usage. KWin did use a lot of CPU while in this configuration though, maybe 6.6 has a leak in the code path we're clearly going into a lot with this configuration. I took a quick look with hotspot, and it seems that Firefox requests the CSD mode every time KWin sends the event that it's actually rendering SSD. It looks like we're doing a lot of work in KWin when the client requests a decoration mode that we ignore anyways... or even if we honor it and the client has already requested the same mode before.
(In reply to Zamundaaa from comment #1) > I only tested this on git master, but I didn't see any excessive amount of > memory usage. KWin did use a lot of CPU while in this configuration though, > maybe 6.6 has a leak in the code path we're clearly going into a lot with > this configuration. > > I took a quick look with hotspot, and it seems that Firefox requests the CSD > mode every time KWin sends the event that it's actually rendering SSD. It > looks like we're doing a lot of work in KWin when the client requests a > decoration mode that we ignore anyways... or even if we honor it and the > client has already requested the same mode before. Worth noting is that both machines are running Nvidia GPUs, so perhaps a driver complication?
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/9402
Git commit 17b18492762d722906e4d5b3c434af2dfce14a38 by Xaver Hugl. Committed on 17/06/2026 at 11:30. Pushed by zamundaaa into branch 'master'. wayland/xdgdecoration: ignore irrelevant preferred mode changes Some clients (Firefox) request the preferred mode for some reason if it's not honored by the compositor, which makes KWin send another configure event, which makes the client send another request, infinitely in a loop. While Firefox shouldn't do that, KWin should also not do a bunch of additional work for no reason. M +3 -0 src/wayland/server_decoration.cpp M +8 -3 src/wayland/xdgdecoration_v1.cpp https://invent.kde.org/plasma/kwin/-/commit/17b18492762d722906e4d5b3c434af2dfce14a38
Git commit cec7616c36f9e4977c7b5e0d16b12c752071a73b by Xaver Hugl. Committed on 17/06/2026 at 12:32. Pushed by zamundaaa into branch 'Plasma/6.7'. wayland/xdgdecoration: ignore irrelevant preferred mode changes Some clients (Firefox) request the preferred mode for some reason if it's not honored by the compositor, which makes KWin send another configure event, which makes the client send another request, infinitely in a loop. While Firefox shouldn't do that, KWin should also not do a bunch of additional work for no reason. (cherry picked from commit 17b18492762d722906e4d5b3c434af2dfce14a38) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +3 -0 src/wayland/server_decoration.cpp M +8 -3 src/wayland/xdgdecoration_v1.cpp https://invent.kde.org/plasma/kwin/-/commit/cec7616c36f9e4977c7b5e0d16b12c752071a73b
Git commit 4d3e2c5bddd2e266e82e2d87c09c71d0908198ac by Xaver Hugl. Committed on 17/06/2026 at 12:32. Pushed by zamundaaa into branch 'Plasma/6.6'. wayland/xdgdecoration: ignore irrelevant preferred mode changes Some clients (Firefox) request the preferred mode for some reason if it's not honored by the compositor, which makes KWin send another configure event, which makes the client send another request, infinitely in a loop. While Firefox shouldn't do that, KWin should also not do a bunch of additional work for no reason. (cherry picked from commit 17b18492762d722906e4d5b3c434af2dfce14a38) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +3 -0 src/wayland/server_decoration.cpp M +8 -3 src/wayland/xdgdecoration_v1.cpp https://invent.kde.org/plasma/kwin/-/commit/4d3e2c5bddd2e266e82e2d87c09c71d0908198ac
What a nasty bug to catch … well done!
(In reply to gyges from comment #7) > What a nasty bug to catch … well done! Yet, there might be another source of memory leakage. I'm using a "merger" of titlebar and tabbar as well (titlebar deactivated, tabs and window controls in *one single bar*) and the memory leakage of Firefox on Plasma was not funny, yet it was not "fatal" and didn't crash the system in minutes. So, I'm inclined to believe that there might be another crazy edge case. Live long and prosper