Bug 416497

Summary: No shadows on GTK menus
Product: [Plasma] Breeze Reporter: David Rubio <david.alejandro.rubio>
Component: gtk themeAssignee: Janet Blackquill <uhhadd>
Status: RESOLVED FIXED    
Severity: normal CC: agrinev98, aoudelet, budinero, bugseforuns, david.alejandro.rubio, dsl944298456, hoperidesalone, nate, zrenfire
Priority: NOR    
Version: 5.20.4   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Attachments: How it looks in KDE. This is the same with the Breeze theme or any GTK theme.
How it looks in MATE. This is how it should look.

Description David Rubio 2020-01-20 15:11:01 UTC
Created attachment 125263 [details]
How it looks in KDE. This is the same with the Breeze theme or any GTK theme.

SUMMARY
Right-click menus and context menus for GTK apps have no shadows at all, even though the CSD shadows are correctly applied to the windows themselves.

STEPS TO REPRODUCE
1. Open a right-click menu or a context menu on a GTK app.

OBSERVED RESULT
There's no shadow at all on the menu.

EXPECTED RESULT
There should be shadows on the menu.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 5.4.13-arch1-1
(available in About System)
KDE Plasma Version: 5.17.90
KDE Frameworks Version: 5.66
Qt Version: 5.14

ADDITIONAL INFORMATION
Comment 1 David Rubio 2020-01-20 15:12:12 UTC
Created attachment 125264 [details]
How it looks in MATE. This is how it should look.
Comment 2 Chris Holland 2020-01-20 16:38:54 UTC
For reference, this is the PR for Gtk shadows. It added support for the _GTK_FRAME_EXTENTS window property.
https://phabricator.kde.org/D24660

----

* Running `xprop`, then clicking Firefox with the default KWin titlebar, it *properly* does not have the _GTK_FRAME_EXTENTS property.
* After entering Customize in Firefox, and unchecking "title bar" to enable CSD, the property exists:
  _GTK_FRAME_EXTENTS(CARDINAL) = 26, 26, 23, 29

I couldn't easily figure out the contextmenu properties using xprop though, since a context menu grabs the mouse.

So I used `watch -n0.5 -- xwininfo -root -tree` and opened and closed the firefox contextmenu.

    Parent window id: 0x0 (none)
      69 children:
      0x3200035 "Firefox"": ("Firefox" "Firefox") 201x234+59+270  +59+270
        1 child:
        0x3200036 (has no name): () 1x1+-1+-1  +58+269
    ...

I noticed the window id remained even when the contextmenu was closed. So I ran:
watch -- xprop -id 0x3200035

I did not see any _GTK_FRAME_EXTENTS property.

    WM_TRANSIENT_FOR(WINDOW): window id # 0x32022c4
    WM_HINTS(WM_HINTS):
                    Client accepts input or input focus: True
                    Initial state is Normal State.
                    window id # of group leader: 0x3200001
    WM_WINDOW_ROLE(STRING) = "Popup"
    XdndAware(ATOM) = BITMAP
    _NET_WM_OPAQUE_REGION(CARDINAL) = 
    _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_POPUP_MENU
    ...

I also tested Gnome Chess, and noticed it's app icon menu did have:

    _GTK_FRAME_EXTENTS(CARDINAL) = 6, 6, 5, 7
    _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_POPUP_MENU
Comment 3 David Rubio 2020-01-30 00:12:48 UTC
(In reply to Chris Holland from comment #2)
> For reference, this is the PR for Gtk shadows. It added support for the
> _GTK_FRAME_EXTENTS window property.
> https://phabricator.kde.org/D24660
> 
> ----
> 
> * Running `xprop`, then clicking Firefox with the default KWin titlebar, it
> *properly* does not have the _GTK_FRAME_EXTENTS property.
> * After entering Customize in Firefox, and unchecking "title bar" to enable
> CSD, the property exists:
>   _GTK_FRAME_EXTENTS(CARDINAL) = 26, 26, 23, 29
> 
> I couldn't easily figure out the contextmenu properties using xprop though,
> since a context menu grabs the mouse.
> 
> So I used `watch -n0.5 -- xwininfo -root -tree` and opened and closed the
> firefox contextmenu.
> 
>     Parent window id: 0x0 (none)
>       69 children:
>       0x3200035 "Firefox"": ("Firefox" "Firefox") 201x234+59+270  +59+270
>         1 child:
>         0x3200036 (has no name): () 1x1+-1+-1  +58+269
>     ...
> 
> I noticed the window id remained even when the contextmenu was closed. So I
> ran:
> watch -- xprop -id 0x3200035
> 
> I did not see any _GTK_FRAME_EXTENTS property.
> 
>     WM_TRANSIENT_FOR(WINDOW): window id # 0x32022c4
>     WM_HINTS(WM_HINTS):
>                     Client accepts input or input focus: True
>                     Initial state is Normal State.
>                     window id # of group leader: 0x3200001
>     WM_WINDOW_ROLE(STRING) = "Popup"
>     XdndAware(ATOM) = BITMAP
>     _NET_WM_OPAQUE_REGION(CARDINAL) = 
>     _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_POPUP_MENU
>     ...
> 
> I also tested Gnome Chess, and noticed it's app icon menu did have:
> 
>     _GTK_FRAME_EXTENTS(CARDINAL) = 6, 6, 5, 7
>     _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_POPUP_MENU

Is it the same on Chromium right click menus? It seems to do shadowing on menus properly on Chromium menus on latest GNOME.
Comment 4 David Rubio 2020-02-15 01:46:36 UTC
Is it safe to change the Plasma version of this bug to 5.18.0 now that it released, or do I keep it at 5.17.90?
Comment 5 Nate Graham 2020-02-15 15:13:03 UTC
Yep, that's fine.
Comment 6 David Rubio 2020-07-23 00:30:04 UTC
As a midly useful note, xfwm4 compositor doesn't seem to render shadows on the firefox menu until "show shadows under popup windows" is enabled. Might be worth looking into how they do it?
Comment 7 David Rubio 2020-09-24 17:56:27 UTC
Probably more useful note, even: Deepin's fork of KWin has this bug fixed. Maybe worth a look there?
Comment 8 Aurélien Oudelet (auroud85_fr) 2021-02-10 15:38:36 UTC
Still valid in
Operating System: Mageia 8
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.76.0
Qt Version: 5.15.2
Kernel Version: 5.10.14-desktop-1.mga8
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-6600K CPU @ 3.50GHz
Memory: 15.6 Gio of RAM
Graphics Processor: GeForce GTX 1660 Ti/PCIe/SSE2

As soon as we set "Breeze" in Systemsettings5 => Application Style => Configure GNOME/GTK Application Style... there is no shadow in GTK right-click and GTK menus.
Comment 9 Artem Grinev 2022-05-14 10:17:53 UTC
For me it worked after some Firefox' update. Could you check if it's still there for you?
Comment 10 Nate Graham 2022-05-14 21:47:52 UTC
Can confirm. Looks fixed now!