Context Menu, X11

[evgeniy-harchenko]

Hello!

I encountered the problem after a recent software update. Now there is a problematic behavior of the context menu. There are two problems, and I think they are related.

The first occurs only in Konsole — maybe elsewhere too, but I haven't found other examples. How to reproduce the issue: right-click on an empty area of the console to open the context menu, then close it by, for example, clicking on a free space. Instead of closing, a different context menu opens. Important: if you open the context menu and then open a submenu — for example, by hovering over "Open Folder With" — and only then close the context menu, it will close as expected, and no additional context menus will open on their own.
In KDE, I always get this issue without exception. In LXQt — very rarely; I don't even know what the conditions for triggering the bug are there.
Maybe this will help, but I noticed that the bug is somehow related to the size of menu-shadow-hint-*. For example, the theme I use had this bug, and as a temporary fix, I simply slightly reduced the menu-shadow-hint-left size in it.

GIF

The second problem seems to affect only KDE.
It's a bug with the desktop context menu. For all context menu levels except the first one, shadows (menu-shadow-*) are displayed incorrectly. This appears randomly when starting a session — sometimes the bug is there, sometimes it’s not. The bug goes away if I restart plasmashell.

GIF

Normal	Bug

I've mainly tested this with this theme: link
but the bugs also occurred with the KvGnome theme, and the first bug is reliably reproduced with the KvYaru theme.

Operating System: KDE neon User Edition
KDE Plasma Version: 6.4.3
KDE Frameworks Version: 6.16.0
Qt Version: 6.9.1
Kernel Version: 6.14.0-24-generic (64-bit)
Graphics Platform: X11
Kvantum: latest git

[tsujan]

Sorry, I don't have KWin 6.4 yet — Manjaro hasn't made it available in Testing, probably because of its X11 bugs — but I use LXQt+kwin_wayland 6.3 without problem. I have no Plasma either (uninstalled it months ago) and log into X11 only for testing its support in LXQt.

I converted this to a discussion because, first, it can't be a problem in Kvantum, and second, someone might help you with KDE 6.4.

[tsujan]

Please also note that KDE devs may not fix their X11 bugs anymore. I'm not sure about that, but apparently, their focus is on Wayland.

LXQt, on the other hand, cares for X11 and will support it as long as Qt and KF do.

[Chiitoo]

I noticed the double context menu happening back in 2025-04-15 already, with kwin-x11 and LXQt.

That would have been around kwin-6.3.4 and konsole-24.12.3.

I noticed it while using the Fusion theme, which I normally use, but later on figured that, for example, the Breeze theme does not trigger it.

I never got to bisecting or reporting the issue at KDE yet still.

[evgeniy-harchenko]

Just tested. Yes, you're absolutely right. When using kwin-x11, I now consistently encounter an issue with the context menu in Konsole under LXQt.

I decided to try using xfwm4 in KDE, and I got a strange result: the context menu in Konsole remained buggy, but the desktop context menu issue seems to have disappeared.

What's also interesting is that if you use kwin-x11 and try to fix the desktop context menu bug by restarting the window manager—it doesn't help. However, restarting plasmashell does solve the problem.

UPD: So, I tried Openbox on KDE. The issue is now gone everywhere, but there’s no compositor either. I installed Picom — the problem reappeared only in Konsole. I couldn’t reproduce it on the desktop.

[tsujan]

I noticed it while using the Fusion theme

This is interesting to me because it reminds me of what I've seen in kdiff3: Under special circumstances and only under KWin (on Wayland), its window may be totally transparent with Fusion or Kvantum, but not with Breeze. It seems to me some KDE devs have started to add Breeze-specific lines to their codes. I hope that's unintentional; otherwise, it'll be a very wrong direction.

[Chiitoo]

Reported at KDE here:

https://bugs.kde.org/show_bug.cgi?id=507511

[evgeniy-harchenko]

@tsujan , hello!

I don't know whether this will be useful, but in KDE Plasma 6.5.5 (or possibly even earlier) a similar bug has appeared, but only on Wayland. The issue is as follows: the window titlebar context menu has no shadows. On X11 this problem does not exist. There is also no issue with other styles (Fusion, Oxygen, etc.). What’s even stranger is that I tested this on LXQt with kwin_wayland 6.5.5, and for some reason the problem does not occur there either.

[tsujan]

If I remember correctly, this isn't something new:

Kvantum/Kvantum/style/themeconfig/ThemeConfig.cpp

Lines 592 to 597 in 79e0cdf

	else if (QString::compare(QGuiApplication::platformName(), "wayland", Qt::CaseInsensitive) == 0)
	{
	/* Wayland is always composited.
	NOTE: Even under Linux, there's at least one situation, where the lack of x11
	doesn't mean Wayland: KWin-Wayland's menus and tooltips are polished
	when the platform name isn't set to "wayland". */

However, it isn't related to the main topic of the current discussion.

[evgeniy-harchenko]

However, it isn't related to the main topic of the current discussion.

Of course, you're right. I just didn't want to clutter the repository with new discussions, so I decided to post here, because the problem looks similar (in both cases we're dealing with shadow‑rendering issues) but it has a different root cause.

In short, if I understood correctly, there is no way to fix the situation with KWin + Wayland + LXQt; the only option is to use a compositor that implements its own rendering of the window titlebar context menu, for example, labwc.

As for the original topic of the discussion - the issue with X11 - after prolonged use of LXQt I continued to encounter this bug, but much less frequently than on KDE. Apparently, this is still some kind of regression in Qt. The bug has poor reproducibility and is generally difficult to catch.

Since many developers are increasingly shifting their focus to Wayland, I don't think they'll pursue finding the root cause of the issue on X11. Given all of the above, I believe the discussion can be closed. Many thanks to all participants.

[tsujan]

there is no way to fix the situation with KWin + Wayland + LXQt

It isn't about LXQt, but no, there's no way to circumvent it because Kvantum's code should remain self-consistent.

[evgeniy-harchenko]

If this is useful to anyone, the problem starts with Plasma 6. Before that, there were no issues.

[evgeniy-harchenko]

For those who encountered the same problem. Here is the patch: fix-kwin.patch

[tsujan]

I re-opened the Discussion for others, who might encounter the same issue, to find it more easily.

[evgeniy-harchenko]

There is news about the first bug, the one with the duplicated menu. The same bug was found again, but this time only in Wayland; I couldn't reproduce it in X11. And once again, Konsole is involved.

If you open some file in Kate (this is important - something must be open), then open the terminal in the bottom panel, right-click in it to bring up the context menu, and then click somewhere in the document area (this is important - clicking in the terminal area will not trigger the bug), a second level of the context menu appears again.

The bug appears with all Styles.

And the bug occurs specifically with Konsole in both Wayland and X11, but after opening the context menu, you need to close it by clicking on the window title - then the bug will definitely appear.

Overall, I'm increasingly thinking that this is actually some kind of Konsole bug or a Qt regression that only manifests itself in Konsole.

1111.webm

Update: Yes, it was Konsole:
https://bugs.kde.org/show_bug.cgi?id=516466#c2
https://bugs.kde.org/show_bug.cgi?id=516466#c4

[tsujan]

Let's choose your last comment as the answer to this Q&A.