Bug 395262

Alex, would you mind having a look here?

I can confirm it.
Looking into it...

So after investigating I believe this visual bug happens when a QMenu is called with popup() instead of exec()
Maybe this is a Qt bug?

In this file if I change menu->popup() to menu->exec() then there is no visual bug, but after I close the menu plasmashell crashes and I don't know how to prevent it from crashing.
https://github.com/KDE/plasma-desktop/blob/master/containments/desktop/plugins/folder/foldermodel.cpp#L1776

But then changing every instance of popup() to exec() would be a big task.

Can anyone with more experience please help me with this?

This bug also affects Dolphin's drag and drop context menu. If you drag and drop an item, the context menu that pops up asking to move, copy, etc. exhibits the blur bug. I'm on Manjaro testing, plasma 5.13.1.

I can confirm the problem on Arch Linux running plasma 5.13.1 under X11.
Blur effect works correctly under Wayland.

At second screen works very well. But after use many days without restart, blur effect start work also at first screen.

>But then changing every instance of popup() to exec() would be a big task.

This isn't an option for plasmashell.

But there shouldn't be a difference from a kwin side - so we need to figure out what's different from an X POV when the different method is called.

Historically there was a difference with when QWidget::polish was called, which affects when QStyle code is triggered, we used to have an issue with oxygen's rounded corners.

(In reply to David Edmundson from comment #7)
> But there shouldn't be a difference from a kwin side - so we need to figure
> out what's different from an X POV when the different method is called.

Kvantum and QtCurve themes that support transparent context menus work without any problem, so this must be a Breeze issue then. I looked at their source code but didn't find anything regarding handling these two types differently.

In breezestyle.cpp the correct code runs, regardless of popup() or exec() call, although for popup() it gets called 3 or 4 times(??).

I'll investigate this further...

This also happens on ringt-click-menu in vlc.

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

@Alex please see https://phabricator.kde.org/D14174 and let me know if we need this in other places

I don't know if it makes sense to fix Qt. QMenu is a horrible piece of code to get changes into as it has so many platform specific behavioural things.

Git commit 42a74c9a79baafb222513f3ffad35b736b708454 by David Edmundson.
Committed on 17/07/2018 at 09:34.
Pushed by davidedmundson into branch 'master'.

Fix blur behind folderview context menus

Summary:
Breeze has

if (!(widget->testAttribute(Qt::WA_WState_Created) ||
widget->internalWinId()))
   KWindowSystem::blur(widget->winId(), ...)

which makes sense as the style should not be creating surfaces in polish
and I don't want to remove it.

This is problematic with QMenu::polish which has a subtle behavioural
change compared to QMenu::exec in that it calls ensurePolish before
creating the surface.

Plasma::ContainmentInterface accidentally has this workaround already
for parent window setting.

Test Plan:
Right clicked on desktop icon
Looked amazing

Reviewers: #plasma, hein

Reviewed By: #plasma, hein

Subscribers: hein, plasma-devel

Tags: #plasma

Differential Revision: https://phabricator.kde.org/D14174

M  +1    -0    containments/desktop/plugins/folder/foldermodel.cpp

https://commits.kde.org/plasma-desktop/42a74c9a79baafb222513f3ffad35b736b708454

(In reply to David Edmundson from comment #12)
> Git commit 42a74c9a79baafb222513f3ffad35b736b708454 by David Edmundson.
> Committed on 17/07/2018 at 09:34.
> Pushed by davidedmundson into branch 'master'.
> 
> Fix blur behind folderview context menus
> 
> Summary:
> Breeze has
> 
> if (!(widget->testAttribute(Qt::WA_WState_Created) ||
> widget->internalWinId()))
>    KWindowSystem::blur(widget->winId(), ...)
> 
> which makes sense as the style should not be creating surfaces in polish
> and I don't want to remove it.
> 
> This is problematic with QMenu::polish which has a subtle behavioural
> change compared to QMenu::exec in that it calls ensurePolish before
> creating the surface.
> 
> Plasma::ContainmentInterface accidentally has this workaround already
> for parent window setting.
> 
> Test Plan:
> Right clicked on desktop icon
> Looked amazing
> 
> Reviewers: #plasma, hein
> 
> Reviewed By: #plasma, hein
> 
> Subscribers: hein, plasma-devel
> 
> Tags: #plasma
> 
> Differential Revision: https://phabricator.kde.org/D14174
> 
> M  +1    -0    containments/desktop/plugins/folder/foldermodel.cpp
> 
> https://commits.kde.org/plasma-desktop/
> 42a74c9a79baafb222513f3ffad35b736b708454

Will this change make it into Plasma 5.13.4? Or we will have to wait for 5.14?

Created attachment 113989 [details]
desktop icon menu

It's very cool that you found a solution. Thank you for helping me out. I would have never guessed this.
However even with the patch applied I still have the glitch.

Heh.
Does this work: 
    menu->setAttribute(Qt::WA_TranslucentBackground);

Created attachment 113992 [details]
video of half-working

Adding this solves it for desktop icon menu:
    menu->setAttribute(Qt::WA_TranslucentBackground);
However this is not the only case of using QMenu::popup() (see video)
Some 3rd party apps use it too.
Can this be done in Breeze theme itself?
Is there any technical possibility that doesn't allow it?

Huzzah, I had some stray code setting that when trying different things :/

I'll have a look at whether we can do it in Breeze. I'm not convinced.

(In reply to David Edmundson from comment #17)
> Huzzah, I had some stray code setting that when trying different things :/
> 
> I'll have a look at whether we can do it in Breeze. I'm not convinced.

it works in QtCurve and Kvantum too, so we should be able to do it in Breeze too, right?

Where is the fix? Bug persists on both Arch Linux (plasma 5.13.5) and neon dev unstable under X11.

(In reply to Dr. Chapatin from comment #19)
> Where is the fix? Bug persists on both Arch Linux (plasma 5.13.5) and neon
> dev unstable under X11.

AFAIK The fix landed a while ago, and works just fine. 
The bug only persists in VLC. Arch Linux + Plasma 5.13.5 intel GPU

Created attachment 114898 [details]
screencast recorded on neon dev unstable

Does anyone else confirm that the problem persists?

My Arch and Neon are running on different computers.
Arch computer has intel hd graphics, neon computer has intel hd 4000.

I also still have the problem.
Here is an attempt to fix it for the desktop icon context menu: D15435

(In reply to Alex Nemeth from comment #22)
> I also still have the problem.
> Here is an attempt to fix it for the desktop icon context menu: D15435

Full link: https://phabricator.kde.org/D15435

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

"drag and drop" copy/paste menu also have this broken blur effect in kde neon 5.13.5

(In reply to umer from comment #25)
> "drag and drop" copy/paste menu also have this broken blur effect in kde
> neon 5.13.5

Same thing in plasma 5.14 beta, Arch Linux.

Under Wayland the bug occurs with the context menu of window decoration. Both neon dev unstable and Arch Linux (plasma 5.14 beta) are affected.

Under X11 the bug occurs with the context menu of plasma notification. For example, press printscreen to open spectacle and save the screenshot. Right click the notification and you can see the bug in the context menu.

Can we reopen this report or we need new reports?

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

I would suggest to file individual reports for the cases where it (still) does not work correctly.

I created new issue but Nate marked it as duplicate of this and closed. Maybe it is better to reopen this one.

Fixing them individually is actually a workaround of the real problem.
I introduced the transparent menu feature. I'm sorry but I have no idea how to really fix this. 
I looked at Kvantum and QSvgStyle where this actually works, but can't figure out what their devs did to achieve this. 
I think currently our best option may be to fix this as workaround in the most obvious places (like we did it with the desktop context menu).

bug 399680 is related

another related report: bug 400092

The issue is still not resolved completely.

*** This bug has been marked as a duplicate of bug 399680 ***