main ← besendorf:feature/avoid-xembed-tray-resize-loop
opened 03:44PM - 18 Aug 26 UTC
## Summary
- read the tray client's actual geometry before docking;
- apply the… existing `32x32` fallback and pre-dock `MSG_CONFIGURE` only to clients whose initial size is `1x1`; and
- preserve the geometry of clients such as Fcitx5 that already provide a usable size.
## Root cause
PR #264 correctly repaired the XEmbed notification and property decoding, and added geometry initialization for tray clients that otherwise remain at `1x1`. However, it applies the `32x32` resize and synthetic configure message to every XEmbed tray client.
Fcitx5 creates its tray window with a valid size and reacts to configure events by updating its size hints and resizing the tray window. Forcing another size before docking can therefore create a configure/resize feedback loop with some dom0 tray implementations. This matches the reported regression where starting Fcitx5 with GUI agent 4.3.19 makes an Xfce dom0 session sluggish and drives `Xorg`, `qubes-guid`, and `xfwm4` CPU usage upward.
The decision must use geometry alone rather than the current `XEMBED_MAPPED` flag. A dock trace showed that `nm-applet` requests docking at `1x1` while that flag is still clear, then sets it shortly afterward. Requiring the flag caused it to remain a white `1x1` square.
This change retains the `1x1` recovery needed by clients such as `nm-applet`, while avoiding an unnecessary geometry change for healthy clients.
Related reports:
- https://github.com/QubesOS/qubes-gui-agent-linux/pull/264#issuecomment-5329664671
- https://forum.qubes-os.org/t/qubes-became-extremely-sluggish-after-a-dom0-update/42922/7
## User impact
Tray clients that start at `1x1` continue to receive the `32x32` initialization introduced by PR #264, including clients that set `XEMBED_MAPPED` after requesting the dock. Clients with an existing usable geometry are only reparented and moved to the embedder origin, restoring the pre-PR size handling for that case.
## Validation
- Built `gui-agent/qubes-gui` from a clean object state with the project's `-Wall -Wextra -Werror` flags on Arch Linux.
- Installed the equivalent v4.3.19 hotfix in an Arch Qubes AppVM with Fcitx5 5.1.21 and `nm-applet` 1.36.0.
- Captured the initial dock state: Fcitx5 arrived at `48x48` with `XEMBED_MAPPED` set and skipped normalization; `nm-applet` arrived at `1x1` with the flag clear and was normalized.
- Confirmed both tray icons were displayed correctly. Their final mapped geometry was `32x32`.
- Replaced and redocked Fcitx5 ten times over 25 seconds: the GUI agent used 0.32% CPU, guest Xorg used 3.40% CPU, and the service remained active with zero restarts.
- Toggled the input method twenty times; the GUI agent consumed 0.01 seconds of CPU.
- During a later 20-second steady-state interval with both clients present, the GUI agent consumed 0.07 seconds and guest Xorg consumed 0.64 seconds of CPU.
- The GUI-agent journal contained only the expected X-server connection and temporary dock-probe messages.
The runtime checks validate the guest-side docking behavior. The dom0-side Xfce process behavior still needs confirmation on an affected system.
## AI assistance disclosure
This change was investigated, developed, and tested with assistance from OpenAI Codex. The author directed the investigation and requested publication; the diff and validation evidence are provided here for maintainer review.