http://bugs.winehq.org/show_bug.cgi?id=60515 Bug ID: 60515 Summary: Notification area icons stop receiving mouse clicks after the system tray host is restarted (GNOME AppIndicator extension, suspend/resume) Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Keywords: source, testcase Severity: normal Priority: P2 Component: winex11.drv Assignee: wine-bugs@list.winehq.org Reporter: brunet.cyril@hotmail.com Target Milestone: --- Distribution: --- Created attachment 82373 --> http://bugs.winehq.org/attachment.cgi?id=82373 traytest.c After the XEmbed system tray host goes away and comes back, Wine re-docks its notification icons, but they no longer receive any mouse input: clicking the icon does nothing, so applications that are only reachable through their tray icon menu cannot be used anymore. A blank 160x20 "explorer.exe" window (the stand-alone tray) also appears and stays on screen; clicking in it does nothing either. On my system this happens after every suspend: the monitors disconnect, GNOME Shell recreates its tray, and from then on every Wine tray icon is dead until the application is restarted. The same thing can be triggered on demand by disabling and re-enabling the GNOME Shell AppIndicator extension, which provides the legacy (XEmbed) tray. The attached traytest.c adds a tray icon and prints the callback messages it receives. The attached terminal output shows the left and right clicks being reported before the tray host restart, and nothing after it. Steps to reproduce: 1. GNOME Shell (Wayland session, XWayland) with the AppIndicator extension and its legacy tray enabled (Ubuntu: ubuntu-appindicators, "legacy-tray-enabled" true). 2. Build traytest.c: x86_64-w64-mingw32-gcc traytest.c -lshell32 -o traytest.exe 3. wine traytest.exe, then click the icon in the top bar: callbacks 0x0201/0x0202 and 0x0204/0x0205 are printed. 4. gnome-extensions disable ubuntu-appindicators@ubuntu.com; gnome-extensions enable ubuntu-appindicators@ubuntu.com (or suspend and resume the machine) 5. Click the icon again. Expected: the callbacks are printed again, as they are after a restart of the application. Actual: nothing is printed; the stand-alone tray window is shown. Additional information (from +systray,+event,+cursor,+x11drv traces): - When the tray host disappears, the docked icon gets WM_CLOSE ("icon 1 no longer embedded"), hide_icon()/show_icon() fail to dock it again and it is added to the stand-alone tray with systray_add_icon(). - When the new tray host announces itself (MANAGER message), hide_icon() is called on the icon that now lives in the stand-alone tray. The driver still considers its window embedded, so WINE_SYSTRAY_DOCK_REMOVE succeeds and icon->display is set to ICON_DISPLAY_HIDDEN before systray_remove_icon(), which then returns early. The icon window stays a WS_CHILD of the stand-alone tray window (which stays visible) while being docked again. - Separately, while the icon window goes back and forth, the window manager (mutter) manages it for a moment and deletes its WM_STATE property when it gets docked. handle_wm_state_notify() takes this as "unexpected WM_STATE 0", the desired wm_state becomes Withdrawn, and window_update_client_config() then ignores every later configure change ("unexpected config (1569,5)-(1585,21)"). The Win32 rect of the icon window stays at -1920,0 while the X window is at 3489,5, so the button events that winex11 receives and maps to (1577,13) are never delivered to the icon window. Tested with Wine 11.0 built from source (with unrelated local changes in other components), clean 64-bit prefix, Ubuntu 26.04.1, GNOME Shell 50.1 (Wayland, XWayland), three monitors. Both code paths look unchanged in current git master (programs/explorer/systray.c hide_icon(), dlls/winex11.drv/event.c handle_wm_state_notify()). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.