Usability bug: Context menu remains open and blocks all input until manually closed

Feedback
,
1

When opening a context menu (right-click menu) in Zorin OS 18 Core and Pro, the menu sometimes remains open in the foreground and blocks all further input (mouse clicks, keyboard) until the menu is closed manually (e.g., by pressing Esc or Alt+Tab). This behavior is reproducible and disrupts normal workflow.

Steps to Reproduce:

  1. Open a file manager (Nautilus) or desktop.
  2. Right-click to open the context menu.
  3. Attempt to interact with other windows or the desktop while the menu is open.
  4. Observe that all input is blocked until the menu is closed.

Expected Behavior:
The context menu should not block input to other windows or the desktop. It should close automatically when clicking elsewhere or lose focus when switching windows.

Actual Behavior:
The context menu stays open and blocks all input until manually closed.

Additional Information:

  • Zorin OS Version: 18 Core and Pro
  • Reproducible: Always
  • Workarounds: Pressing Esc or Alt+Tab sometimes helps but isn't intuitive

This feedback was also shared via Send Feedback - Zorin OS

2

This is abnormal behavior.

Clicking anywhere outside of the context menu should interrupt it.
To try to narrow this bug down, can you please outline:

  • Whether you are logging in on Wayland and if you have tested this on Xorg (Wayland is a bit more restrictive on Context Menu behavior and prone to faults).
  • Your GPU, whether dedicated or integrated - if dedicated, which driver

sudo lshw - C video

  • If you have added any Gnome Extensions (This may be a Mutter and Compositor issue)
2 Likes
3

This isn't happening for me, so it doesn't look like a general Zorin problem.

3 Likes
4

It really smell a Wayland issue... you are right

2 Likes
5

Welcome to the Forum!

I tried it and it does exactly what You wrote:

Of Course, You have to click first to get the Right-Click Menu away and then You can interact. But when You click somewhere it should disappear automatically.

I'm on Wayland and can't confirm that Behavior.

1 Like
6

Thanks! I forgot about the extensions! Disabled the non-system ones, made a relogin and the bug is gone. Fun fact, I re-enabled them one after another and the bug did not reappear, so I can't even narrow down which one was the cause.

Thank you all and apologies for using your time for such a stupid mistake overlooking the custom extensions.

2 Likes
7

Unfortunately there's more to it than I thought. My issue is back,

  • also with a new user (clean profile) and
  • additionally all extensions disabled.
  • It seems to affect Wayland sessions only, X11 works as expected.

Could you please remove the [Solved] tag in title? I can't modify it any more.

@Aravisian the lshw -C video output is as follows:

  *-display                 
       description: VGA compatible controller
       product: TigerLake-LP GT2 [Iris Xe Graphics]
       vendor: Intel Corporation
       physical id: 2
       bus info: pci@0000:00:02.0
       logical name: /dev/fb0
       version: 01
       width: 64 bits
       clock: 33MHz
       capabilities: pciexpress msi pm vga_controller bus_master cap_list rom fb
       configuration: depth=32 driver=i915 latency=0 mode=1920x1080 resolution=1920,1080 visual=truecolor xres=1920 yres=1080
       resources: iomemory:600-5ff iomemory:400-3ff irq:185 memory:601c000000-601cffffff memory:4000000000-401fffffff ioport:3000(size=64) memory:c0000-dffff memory:4100000000-4106ffffff memory:4020000000-40ffffffff
8

Amended thread title as requested.

1 Like
9

That is worth highlighting.
So just issues if Wayland is used?
Expected functionality is good and repeatable each and every time under X11?

10

Confirmed. I did repeated interchanged Wayland / X11 logins using the freshly created test user.
Using X11 behaviour is always as expected, using Wayland always shows the described issue for my test user.

Installation history if that matters: Started with a Zorin 18 Core beta installation, which was automatically updated to 'stable' and then to 18.1 Core. Although I bought a Pro license from the beginning, never cared to upgrade to Pro until now just to see if the behaviour changes, which didn't.
I'm telling because there might be a risk of leftover files from the beta. To my understanding that shouldn't happen, but just in case i mention it.

11

Just to understand and maybe give some help for other users, could you show me the content of ~/.local/share/nautilus-python/extensions

12

Directory /home/test/.local/share/nautilus-python does not exist for this new created and affected test user, although this application has been run and used for this case. /home/test/.local/share/nautilus/ is the next best match which doesn't have file or directory extensions.

13

OK so it's not a nautilus extension problem, thank you

1 Like
14

Thanks for checking. Just to avoid misunderstanding, it's not limited to Nautilus. I just chose this app for the test case because it's basic.

2 Likes
15

Then it sounds like a Wayland Issue. You should stay on X11 and use that.

16

Thanks, would be ok for me. Still others might stumble over the same because Wayland is the default. They might have the impression that the session locked up, if they don't find out they need to close context menu of their application first, or don't directly identify this open menu.

If you need more logs etc for narrowing down this phenomenon, let me know.

1 Like
17

One of the questions users are frequently asked is "have you tried switching it OFF and ON again?" "are you on Wayland or X11? If Wayland, try switching to X11"
But you are correct, Wayland is unfortunately the ZorinOS default, despite its continued shortcomings.

18

Wayland is a compositor, and this is a Graphics Stack compositing issue.
The I915 driver is pretty stable, now.

19

Same issue for me. It doesn't happen if I disable the desktop icons extension (I even tried other similar extensions and the problem persists).

With all the other extensions, the issue can't be reproduced.

1 Like
20

Thanks for confirming that I'm not the only one (when using Wayland).
At first I thought, it is 100% reproducible because it persisted reboots and also disabling all (!) gnome shell extensions for the test user I created for testing this.

As it turns out now, for me the issue vanishes for a seemingly random amount of sessions and then out of nowhere, the issue is back and again persists sessions and reboots.

Of course people can just switch to X11 as a workaround, but let's also think of improving the situation when the default setting with Wayland is used. It might be valuable to track this behaviour down to its root source.