https://bugs.kde.org/show_bug.cgi?id=524543
Bug ID: 524543
Summary: Breeze paints a duplicate close button when a window
becomes fixed-size after mapping
Classification: Plasma
Product: kwin
Version First 6.7.3
Reported In:
Platform: Bazzite
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: decorations
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 195341
--> https://bugs.kde.org/attachment.cgi?id=195341&action=edit
Script to reproduce issue
## Summary
Breeze leaves an extra, non-functional close button painted in the titlebar
when a
window becomes fixed-size *after* it has been mapped.
The extra button is a pixel-identical copy of the real close button, has no
tooltip, does nothing when clicked, and disappears the moment it is clicked —
i.e. as soon as anything forces the decoration to repaint.
## Steps to reproduce
The attached `kwin-phantom-close-button.py` is a self-contained
[uv](https://docs.astral.sh/uv/) script, so it brings its own interpreter and
needs no system tkinter. The two runs differ **only** in when
`resizable(False, False)` is called.
1. `uv run kwin-phantom-close-button.py after` — count the titlebar buttons
2. `uv run kwin-phantom-close-button.py before` — count the titlebar buttons
(`python3 kwin-phantom-close-button.py after` works just as well on a system
whose Python was built with tkinter.)
Verified with the interpreter uv installs, CPython 3.12.13 with Tk 9.0, and
with
the distribution's Tk 8.6.
## Observed result
| run | buttons | button centres (px from the window's left edge) |
| --- | --- | --- |
| `after` | **3** — minimize, close, close | 505, 553, 601 |
| `before` | 2 — minimize, close | 553, 601 |
Both windows have the same right edge, so the `after` case gains an extra
button
and pushes the others left. Cropping the two right-hand glyphs from a
screenshot
of the `after` window and differencing them gives a maximum per-pixel
difference
of **0** — it is the close button painted twice, not a mis-drawn maximize
button.
Clicking the extra button does nothing except make it vanish.
## Expected result
Both windows show minimize + close. A window that stops being maximizeable
after
mapping should have its titlebar repainted, not keep the old button painted.
## Software/OS versions
- Operating System: Bazzite 44.20260801.0 (Fedora Kinoite based)
- KWin: 6.7.3 (`libkwin.so.6.7.3`)
- Qt: 6.11.1
- KDE Frameworks: 6.28.0
- Window decoration: Breeze, **default** button layout (no `ButtonsOnRight` in
`kwinrc`)
- Session: Wayland; the client is X11 via XWayland
- Reproduced with both Tk 8.6 and Tk 9.0
## Additional information
The window manager appears to *know* the correct state — only the painting is
stale:
- `_NET_WM_ALLOWED_ACTIONS` on the finished window correctly lacks
`_NET_WM_ACTION_RESIZE` and `_NET_WM_ACTION_MAXIMIZE_VERT/HORZ`
- `_NET_FRAME_EXTENTS` is `0, 0, 56, 0`, and the titlebar measures exactly
56px,
so the extra button really is inside the window's own decoration
- `_MOTIF_WM_HINTS` is **not** set; the application only changes
`WM_NORMAL_HINTS` (`resizable()` sets min size == max size)
- the real Close button shows a "Close" tooltip; the extra one shows none
- the size-hint change is the only trigger: the reproducer sets no other window
attributes (no `-topmost`, no window type, no transient parent)
This may share the double-buffered decoration state described in
[Bug 514600](https://bugs.kde.org/show_bug.cgi?id=514600) ("Border size is
double-buffered state. It can change later when the client acknowledges a
configure event with the next decoration state"), though the symptom there is
misalignment rather than a duplicated button.
Not tested: whether a native Wayland client that changes its size constraints
after mapping shows the same artifact.
--
You are receiving this mail because:
You are watching all bug changes.
