Skip to content

Tray icon unresponsive after first click when window is hidden (tray_activate bug) #1062

Closed

Description

@jatofe999

Describe the bug
The tray icon becomes unresponsive after the first click. The first click works
correctly (shows the menu or the main window), but all subsequent clicks produce
no response. The tooltip still shows correctly, meaning the process (mintUpdate.py)
is alive but not reacting to clicks.
Screenshots
If applicable, add screenshots to help explain your problem, you can just drag & drop them here.

To Reproduce

  1. Log in to a Cinnamon session
  2. Click the update manager tray icon → works correctly
  3. Close the menu or window
  4. Click the tray icon again → no response
  5. Repeat clicks → still no response

Expected behavior
A clear and concise description of what you expected to happen.

Distribution:

  • [ x] Linux Mint
  • LMDE
  • Other (please specify)

Software version:
7.1.4

Logs:
Copy & paste the log output from Update Manager > View > Information here.

Crash report:
If you are reporting a crash, please run mintupdate from a terminal window, reproduce the crash and copy & paste any output from the terminal window here.

Additional context
Add any other context about the problem you think might be relevant.

Locale:
If the problem is with text not getting displayed correctly, paste the output of the terminal command locale.

Root cause
The bug is in the tray_activate method (mintUpdate.py, line ~1239):

def tray_activate(self, time=0):
    try:
        focused = self.ui_window.get_window().get_state() & Gdk.WindowState.FOCUSED
    except:
        focused = self.ui_window.is_active() and self.ui_window.get_visible()

    if focused:
        self.hide_window()
    else:
        self.show_window(time)

When the window is hidden, get_window().get_state() still reports
Gdk.WindowState.FOCUSED = True. As a result, tray_activate incorrectly
evaluates focused = True and calls hide_window() instead of show_window(),
even though the window is already hidden.

Fix
Add a visibility check to the focused condition:

focused = (self.ui_window.get_window().get_state() & Gdk.WindowState.FOCUSED) and self.ui_window.get_visible()

This ensures the window is only considered "focused" if it is both focused AND
actually visible, preventing the incorrect hide on subsequent clicks.

This one-line change fixes the issue completely (tested: 10 consecutive clicks
all working correctly).

Activity

  1. pablovercosa commented on Oct 23, 2026

    @pablovercosa

    Additional reproduction and confirmed workaround from another affected system.

    Environment: Linux Mint 22.3, Xfce on X11, Compiz 0.9.14.2, mintupdate 7.1.4, Intel UHD Graphics 630.

    Reproduction: Left-clicking the Update Manager tray icon opens the main window the first time. After closing the window, clicking the tray icon again does nothing, although the icon and process remain active. Minimizing and restoring another window could make the Update Manager appear again.

    While the issue was occurring, the Update Manager window existed but was unmapped (Map State: IsUnMapped, WM_STATE: Withdrawn) while _NET_WM_STATE_FOCUSED was still set. In mintUpdate.py, tray_activate() checked the focused state without first checking visibility, so it called hide_window() again instead of show_window().

    Confirmed workaround: Require the window to be visible before treating it as focused:

    focused = self.ui_window.get_visible() and (
    self.ui_window.get_window().get_state() & Gdk.WindowState.FOCUSED
    )

    A regression test reproduced the failure before this guard and passed afterward. After restarting mintUpdate with the change, tray-icon clicks worked again. Setting Compiz’s focus-prevention level to 0 did not help, so that setting was reverted. This workaround is currently applied locally to the installed mintUpdate.py.

    A similar symptom was noticed with Chrome’s download-location chooser, but that separate case has not been verified against this workaround.

  2. mtwebster commented on Oct 23, 2026

    @mtwebster
    Member

    Probably fixed by b73a008, though I originally targeted it at wayland sessions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions