Bug Report: XFCE Mouse Clicks Intermittently Freeze on New Window/Menu Open

After logging into the XFCE desktop environment, mouse clicks intermittently stop registering across most of the desktop. The mouse cursor still moves freely, and hover effects sometimes work on certain elements (e.g., some status bar applets), but actual clicks on window title bars, close/minimize/maximize buttons, the desktop background, and most panel elements (including the main menu button) become unresponsive.

The problem is consistently triggered when a new window is opened, most notably by clicking the XFCE menu button (bottom-left). It also occurs when opening applications like Firefox or Thunar.

Affected Components:

XFCE Window Manager (xfwm4)

XFCE Panel (xfce4-panel)

Mouse input processing within the XFCE session.

System Information:

Operating System: Linux Mint 22.1 "Xia" XFCE Edition

Kernel Version: 6.8.0-63-generic

Graphics Card: Intel Corporation CoffeeLake-S GT2 [UHD Graphics 630]

Graphics Driver: i915 (Kernel driver in use: i915)

Steps to Reproduce (Consistent and Reproducible):

Perform a clean installation of Linux Mint 22.1 XFCE Edition.

After logging in, ensure that display compositing is deactivated in "Ajustes del gestor de ventanas" (Window Manager Tweaks) -> Compositor tab. (The problem occurs whether compositing is on or off, but this step ensures a consistent test environment). Reboot the system.

After logging back in, the mouse clicks will initially work.

Click the bottom-left XFCE menu button.

Observe: Mouse clicks will immediately become unresponsive across most of the desktop. The menu will remain open, but cannot be interacted with via mouse. Hover effects may cease on many elements.

(Optional): Open a terminal using keyboard shortcut (Ctrl + Alt + T).

Run xfwm4 --replace.

Observe: Mouse clicks are temporarily restored. Dragging an active window (e.g., the terminal) by its title bar often fully "wakes up" the input.

Observe: The problem will return as soon as another new window is opened (e.g., clicking the menu again, or launching Firefox/Thunar).

Expected Behavior: Mouse clicks should always register and interact correctly with all desktop elements and application windows without becoming unresponsive.

Actual Behavior: Mouse clicks intermittently stop working across most of the desktop after new windows are opened, requiring a manual restart of xfwm4 to temporarily restore functionality.

Relevant Log Output (from tail -f ~/.xsession-errors when problem occurs):

From xfwm4 (Window Manager):

(xfwm4:PID): xfwm4-WARNING **: HH:MM:SS.ms: unmanaged net_wm_state (window 0x..., atom "_NET_WM_STATE_STAYS_ON_TOP")

(Note: The PID and hexadecimal window ID will vary, but the warning message is consistent.)

From Firefox (when opened/interacted with):

[Parent PID, Main Thread] WARNING: ../../../gobject/gsignal.c:3633: signal name 'text_caret_moved' is invalid for instance '0x...' of type 'MaiAtkType21': 'glib warning', file /builds/worker/checkouts/gecko/toolkit/xre/nsSigHandlers.cpp:201
(firefox:PID): GLib-GObject-CRITICAL **: HH:MM:SS.ms: ../../../gobject/gsignal.c:3633: signal name 'text_caret_moved' is invalid for instance '0x...' of type 'MaiAtkType21'

(Note: These critical errors appear repeatedly when Firefox is active and the mouse issue occurs.)

From Thunar (when opened/interacted with):

(Thunar:PID): GLib-GIO-CRITICAL **: HH:MM:SS.ms: GFileInfo created without standard::size
(Thunar:PID): GLib-GIO-CRITICAL **: HH:MM:SS.ms: file ../../../gio/gfileinfo.c: line 1845 (g_file_info_get_size): should not be reached

Workarounds:

Running xfwm4 --replace in a terminal (Ctrl + Alt + T) temporarily restores mouse functionality.

Dragging a Firefox tab out to create a new window also temporarily restores functionality, likely by forcing xfwm4 to re-initialize its state.

Troubleshooting Performed (and results):

Reinstallation of input drivers (xserver-xorg-input-libinput xinput): Temporarily resolved, but problem returned.

Timeshift Restore: Restoring to a previous working snapshot did NOT prevent the problem from re-occurring.

libinput debug-events: Confirmed that the mouse hardware and libinput driver are correctly registering all button presses/releases and movement events. The problem occurs higher up the software stack.

XFCE Compositor Test: The problem persists even when XFCE's built-in compositor is explicitly deactivated in "Window Manager Tweaks".

Clean XFCE Configuration Test: The problem still occurs even after moving the ~/.config/xfce4 directory to force a completely default XFCE desktop environment. This rules out user-specific configuration corruption.

Observation of Gestor de ventanas (Window Manager) settings panel: The options within this panel became erratic and inconsistent, suggesting severe instability in xfwm4's configuration management.

This bug severely impacts desktop usability and appears to be a core issue within XFCE's window management, possibly related to its interaction with GTK/ATK libraries and Intel graphics on the Ubuntu 24.04 base.