Dear Maintainer, ZoiteChat's main window can unexpectedly increase in size when it is hidden to the system tray and then restored. The problem occurs very frequently, although it does not happen on every hide/restore cycle. Steps to reproduce: Enable "minimize to tray when closing the window". Open ZoiteChat and resize the window to a relatively small size. Press the title-bar close button. ZoiteChat is hidden to the system tray instead of exiting. Restore ZoiteChat by clicking its system-tray icon. Repeat steps 3-4 several times. Actual result: The window often becomes bigger after being restored, particularly vertically;and frequently it extends beyond the screen. In some cases, the window also becomes impossible or very difficult to resize manually. The issue is intermittent: it occurs frequently, but not on every restore. * Restoring the window from the system tray should preserve its previous size and position. * Normal window-manager minimize/restore through the taskbar does not reproduce the problem. * The issue happens under LXDE (lxpanel) and Labwc (waybar). The problem appears to be specific to ZoiteChat's system-tray hide/restore path. Bye!
Hi Awtul, Thanks for your bug report. I installed a sid in a VM with LXDE and tested this according to your directions. Unfortunately, I wasn't able to reproduce the issue, even after closing ZoiteChat to the tray and restoring it 15-20 times. Can you make a new test user account and see if the issue still happens there? It may be related to some configuration cruft in your user profile. Thanks, Jesse Rhodes (sney)
Hi! I tested this with a completely fresh user account, using the default Labwc and Waybar configurations. The problem is still reproducible. With the new user, I launched ZoiteChat, set the window to a diferent specific sizes, and then repeatedly minimized/closed it to the system tray and restored it. On restoration, the window becomes mostly maximized. The only ZoiteChat settings I changed were: "Close and minimize to tray" and some settings related to file transfers. No other desktop or window-manager configuration was changed. This makes it unlikely that the problem is caused by configuration cruft in my original user profile. * I don't use Lxde/X anymore. I'm on a pure Labwc Wayland. Bye! Awtul (awal1)
Ok, with labwc and waybar I saw similar behaviour: If I launch zoitechat, resize it, and close it to the tray, it restores to the original size it was at launch. (i.e. it also restores to a smaller size if I resize it to be bigger.) Since it doesn't do this in plasma under wayland, or in lxde, I'm not sure this is a bug with zoitechat specifically, but forwarding upstream anyway to make sure.
One final technical observation from my testing, in case it is useful for the upstream investigation. I captured the Wayland protocol traffic with `WAYLAND_DEBUG=1` while reproducing the tray hide/restore behaviour. The trace shows repeated `xdg_toplevel.configure` negotiations, together with repeated changes to the client's `xdg_toplevel.set_min_size()` hints while the main window is being created/restored and while the connected channels and UI are changing. The resulting geometry is not simply a maximized window: in the affected cases the restored window can become close to the available screen size while still behaving as a normal, non-maximized window. Its resulting geometry is also not consistent between restores. This seems relevant because ZoiteChat's `mg_configure_cb()` handles the main-window geometry from GTK configure events. When geometry saving is enabled and the window is neither maximized nor fullscreen, it obtains the current position and size using `gtk_window_get_position()` and `gtk_window_get_size()` and stores them in `hex_gui_win_left/top/width/height`. GTK documents that `gtk_window_get_size()` returns the current negotiated window size and that, depending on the windowing system and window-manager constraints, it may differ from a size previously requested by the application. GTK also recommends obtaining the size in response to a size-change notification such as `configure-event` to avoid potential race conditions. I therefore think the interaction between ZoiteChat's geometry save/restore logic, GTK window sizing, and the Wayland configure sequence is worth investigating in the tray hide/restore path. I am not claiming this identifies the root cause; this is simply the part of the application/window-system interaction that appears most relevant from the captured behaviour. Thanks!