Chromium UI buttons (maximize/minimize/close) unresponsive after restoring from minimized state in Wayland

[ffs-akl]

When Chromium is minimized to the taskbar/bar and then restored, its top-right CSD (Client-Side Decoration) window control buttons (minimize, maximize, close) lose interactivity and become completely unresponsive to mouse clicks.
System Environment
Dragging the Chromium window with the mouse (e.g., forcing it from maximized to a normal floating state) immediately restores the functionality and responsiveness of the CSD window buttons.

Kooha-2026-08-07-20-51-32.mp4

OS: Arch Linux
WM/Compositor: shojiwm-git-0.0.1.alpha.r203.g8d35905

Browser: Chromium 151.0.7922.108 (running natively on Wayland)

Comparison: Issue does not occur with native GTK4/Adwaita applications (e.g., gnome-text-editor).

[ffs-akl]

This issue has been reproduced on both shojiwm and niri. this is likely an upstream Chromium bug.

[Everesh]

yep, this is for sure a chromium thing

These client side decorations should be emitting xdg_toplevel requests to set/unset the minimized/maximized states, here shoji could be mishandling the window state machine if it were to no-op some of these events, but if even the close button is unresponsive, its the client that is misbehaving. There is no request, no event, no nothing for the compositor to handle on that, its just an internal call to teardown the application.

[ffs-akl]

I tested this on labwc and found that Chromium does not have this issue. Others using Plasma and GNOME also reported no such issue on Mutter and KWin. Since niri is a scrolling-tiling compositor that doesn't have a traditional minimize feature in the first place, it can't be used to test this problem.

Based on this, I suspect this issue is likely caused by shojiwm, so I have reopened the issue.