[Linux][App] Right-clicking the top draggable title-bar area blocks mouse input across the desktop on GNOME X11
What version of the Codex App are you using (From “About Codex” dialog)?
26.803.81509 (Ubuntu package version)
What subscription do you have?
Unknown (not available from the local diagnostics used for this report)
What platform is your computer?
Linux 6.8.0-136-generic x86_64 x86_64
- Ubuntu 22.04.5 LTS
- GNOME Shell 42.9
- X11 session (
XDG_SESSION_TYPE=x11) - Electron runtime 42.3.0 / Chromium 151.0.7922.76
- NVIDIA GeForce RTX 2060, driver 595.84
What issue are you seeing?
Right-clicking the blank draggable area at the top of the Codex App window, between the application menu and the window controls, causes mouse interaction to stop working across the entire desktop.
The desktop appears frozen because mouse clicks no longer work in Codex or other desktop areas. Keyboard window switching with Alt+Tab still works, so the desktop session itself is still running.
This looks like an invisible native context/window menu or an X11 pointer grab that is not released.
What steps can reproduce the bug?
- Run the Codex App on Ubuntu GNOME using an X11 session.
- Open the main Codex window.
- Right-click the blank top draggable/title-bar area, to the right of the Help menu and to the left of the minimize button.
- Try clicking anywhere in Codex, another application, or the desktop.
- Observe that mouse interaction is blocked while Alt+Tab continues to switch windows.
What is the expected behavior?
Right-clicking the draggable title-bar area should either display a visible system window menu or do nothing. It must not retain a mouse/pointer grab or block interaction with the rest of the desktop.
Additional information
The Codex process is running with --ozone-platform=x11.
Around the affected interaction, GNOME Shell repeatedly logged messages similar to:
Can't update stage views actor <unnamed>[<MetaSurfaceActorX11>:...>] is on because it needs an allocation.
Can't update stage views actor <unnamed>[<MetaWindowActorX11>:...>] is on because it needs an allocation.Possible area to investigate: the Electron custom draggable region, native window context-menu handling, and X11 pointer-grab cleanup on GNOME/Mutter.