Created attachment 132629 [details]
Context menu

Created attachment 132630 [details]
Drop menu

I noriced this bug on Arch Linux and neon unstable after the fix for bug 399680.

Created attachment 132678 [details]
Drop menu with light theme

Can confirm. It does seem to be fallout from the fix for Bug 399680.

Andreas, would yo mind having a look?

Hey all! Thanks for bringing this up. I've been looking into this for a bit but I'm having a hard time tracking down the root cause. 

It appears that some transparent menus in X11 (like the drop menu) are totally missing an alpha channel! See my attachment with the KWin debug console.

I think my fix moved the glitch into the border; though it isn't the reason those windows are lacking transparency. 

These windows seem fine in Wayland, except for the "More Actions" KWin menu. 

I think this could be an issue in Breeze, or Qt. If anyone has any ideas I'm all ears

Created attachment 132782 [details]
Drag Menu With KWin Console

Hey all!

I've spent some more time tracking this down. It appears breeze popups shown with widget->popup() (i.e. asynchronously) exhibit this problem. Popups shown with widget->exec() (i.e. synchronously) do not. 

Furthermore, if the popup has the translucency flag set before popup() is called then the problem goes away.

It appears (in X11) that after a certain moment, Qt will ignore the translucency. With exec() the moment is before polish(), and in popup() the moment is after polish(). 

I dug around the Qt bug tracker and found this. I believe this is the root cause of the issue, and after this is fixed the issue should fix itself :D 

https://bugreports.qt.io/browse/QTBUG-60822

Thanks Andreas!

Is there anything we can do to work around it on our side? Qt being what it is, there's probably not much chance of a fix unless one of us actually goes and fixes it in the Qt code. Would you be interested in having a go at that?

No worries Nate!

I'm afraid there's no workaround that I could see, at least from the Plasma side.  I plan to dive into the Qt code soon to either fix it or find a workaround, but that will probably take some time, considering how massive it is.

Can we remove these borders? It seems to me that menus looks better without borders.

*** Bug 429031 has been marked as a duplicate of this bug. ***

*** Bug 430263 has been marked as a duplicate of this bug. ***

*** Bug 430567 has been marked as a duplicate of this bug. ***

Dupes piling up, marking as VHI.

I made a Qt patch and when I observed the same as as Andreas that popup() and exec() are different. Unfortunately this is not something we can easily workaround in breeze (aside from a really horrible hack I tried)

https://code.qt.io/cgit/qt/qtbase.git/commit/src/widgets/widgets/qmenu.cpp?id=36b1d37cef09769eea22f78d77440ac4c5d008d8

Git commit 20602d44341fd11de5a8221aa739ad35f1fcc988 by Nate Graham, on behalf of David Redondo.
Committed on 15/01/2021 at 16:18.
Pushed by ngraham into branch 'master'.

Restore correct menu border color

cac4b544dbbadc5bcd57ae37ac333383bf44c2ab introduced drawing separators
of transparent QMenus with WindowText color with 0.25 opacity. While the change
in drawMenuItemControl uses the correct condition, drawPanelMenuPrimitive
checked whether the widget had an alpha channel. This is wrong because we set
Qt::WA_TranslucentBackground always on all menus. The very low opacity made it
look like the section headers, separators and highlight were drawing outside of
the menu.

M  +2    -2    kstyle/breezestyle.cpp

https://invent.kde.org/plasma/breeze/commit/20602d44341fd11de5a8221aa739ad35f1fcc988

This was actually not fixed by that commit as it was a different bug, just in the same locations

is this bug really fixed? Or is it a (not fixed according to URL) Qt bug?
It's stiil happening on X11 session of neon unstable.

Operating System: KDE neon Unstable Edition
KDE Plasma Version: 5.21.80
KDE Frameworks Version: 5.82.0
Qt Version: 5.15.2
Graphics Platform: X11

>is this bug really fixed? Or is it a (not fixed according to URL) Qt bug?
It's stiil happening on X11 session of neon unstable.

Note that patch only made it to 5.15 after 5.15.2, but maybe when distributions start using or 5.15 branch it will be better.

If you can see it not everywhere but only in one specific location it could be that it forces creating the platform window to early and we can look at that.

Thanks David.
On neon unstable hamburger menu of System Settings and drop menu of Dolphin
are affected. But I can't reproduce on Arch Linux running KDE Qt.