Bug 375930

here is log which show by no working icon in systemtray
Could not find DBusMenu interface, falling back to calling ContextMenu()
Could not find DBusMenu interface, falling back to calling ContextMenu()
Could not find DBusMenu interface, falling back to calling ContextMenu()
Could not find DBusMenu interface, falling back to calling ContextMenu()
Could not find DBusMenu interface, falling back to calling ContextMenu()
Could not find DBusMenu interface, falling back to calling ContextMenu()
Could not find DBusMenu interface, falling back to calling ContextMenu()

I also see this issue on plasma 5.9 testing packages for kubuntu.

In my case, hexchat icon and Firetray icon for thunderbird.

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

Oddly enough, pidgin works for me, but kalu is broken. Left and middle-click work, but when I right-click, nothing happens. Every time I right-click, I immediately get the following message.

    (kalu:24762): GLib-GObject-CRITICAL **: g_object_set_data: assertion 'G_IS_OBJECT (object)' failed

I also first saw this in Plasma 5.9.0, although it's still present in 5.9.1. I'm running Arch Linux. Also, there are apparently some other gtk apps that are broken too, e.g. keepass, cryptkeeper, xchat [1].

[1] https://forum.kde.org/viewtopic.php?f=289&t=138796&p=371703#p371703

maybe something with GTK2 my pidgin and pasystray etc. seems compiled in GTK2.

(In reply to TOM Harrison from comment #5)
> maybe something with GTK2 my pidgin and pasystray etc. seems compiled in
> GTK2.

How do you tell which gtk an application is compiled with? FWIW kalu has a dependency on gtk3 in Arch Linux.

some of the application of has this kind of error it seems compiled in libgtk2. I has application compiled on GTK3 like gcdemu. it work fine.

this is my libgtk2

libgtk2.0-0:amd64                               2.24.30-1ubuntu1

I do not know that is correct gtk2 version or not.

FWIW nothing happens with backintime when I right click. I'm fairly sure it's qt-based (depends on python-pyqt5 in Arch).

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

@David Edmundson I'm not sure if it's the same. That bug states it's in Plasma 5.6.5.1. However, this current bug is certainly a new regression introduced in 5.9.0. Prior to this, it was working fine for me, and seemingly for the other two reporters. Also, as stated here, I see this bug in backintime's qt icon, whereas the other bug only states gtk.

Regression found.
it's introduced by b9af99140365c8c8cf4e3744af7e13b35c35fa18

which changes SNI behaviour to activate from onClicked to onReleased

That is messing with the xembed code that relays the mouse signals to the legacy as now at the time of the sending the signal the mouse is released which is confusing the client.

Git commit 27b1030756002e91b60ba51483efe9c2c477d16e by Kai Uwe Broulik.
Committed on 08/02/2017 at 10:03.
Pushed by broulik into branch 'Plasma/5.9'.

[System Tray] Part Revert "Trigger context menu on press" as this breaks xembedsniproxy

This part reverts commit b9af99140365c8c8cf4e3744af7e13b35c35fa18 which
changes plasmoids and SNI items to activate on mouse release instead of
mouse click.

This messes with xembedsniproxy which is relaying the mouse press
signals to the exembed client. Now at the time of relay, if the client
application queries the mouse state itself it's going to be wrong and
that breaks GTK.
FIXED-IN: 5.9.2

Reviewed-By: David Edmundson

M  +1    -5    applets/systemtray/package/contents/ui/items/AbstractItem.qml
M  +13   -14   applets/systemtray/package/contents/ui/items/StatusNotifierItem.qml

https://commits.kde.org/plasma-workspace/27b1030756002e91b60ba51483efe9c2c477d16e

(In reply to Kai Uwe Broulik from comment #12)
> https://commits.kde.org/plasma-workspace/
> 27b1030756002e91b60ba51483efe9c2c477d16e

Thanks all, I can confirm that applying this patch fixes this bug for me. Cheers.

I have applied the specified patch over the 5.9.1 version of the plasma-workspace package at the ArchLinux and the issue with right click have gone.
But now there is another inconvenient behaviour of the KDE-icons in the system tray. When I do a right click at the, lets say, Network's icon, then chose the (only in this example) "Configure Network Connections..." item from the popped up menu and then do a left click at any place in the Panel (even at the Panel which placed at the second screen) then... the "Networks" plasmoid appears, as if I do a left click at the Network's icon in the tray.
Moreover, if I do a right click at the same icon, then press the Esc key, then try to do a right click at any place inside of the Panel, then... nothing happened. I.e., it looks like the first right click "eats" the second one.
Moreover, there is one more inconvenient (at my point of view) scenario of a behaviour. Though it relates to that fact that the KDE reacts on the press of the right mouse button, not the release. If I work at a dual-screen system, then the KDE (or Qt?) "thinks" that the working area in the main screen propagated over the Panel too, which is by itself the independent and old issue of the KDE (or Qt?). I make this conclusion based on that fact, that when I switch off the second monitor, than a several kinds of the confirmation-like popups, which go from a couple of a several kinds of an applications (Qt4's skype, Qt5's viber, GTK's thunderbird etc), does not overlap the KDE Panel. But if I connect the second monitor, then they do. This behaviour is propagated to a popup menu, which may appeared on the right click at the tray icons: when the second monitor is connected to the system, then the popup may appeared under the mouse pointer. And now is that, which I wrote so many for: if the second monitor is connected and if I press a right button at a KDE's tray icon (the popup menu of this icon may appeared on this event) and if I move the mouse a little and then release the right button, then a menu item, which will found under the mouse pointer, will be activated. All of this takes so many of the text to describe it, but it may take so little of the time to occur, that you may to be surprised: "What was happened?.."

(In reply to Serge Roussak from comment #14)
> But now there is another inconvenient behaviour of the KDE-icons in the
> system tray. When I do a right click at the, lets say, Network's icon, then
> chose the (only in this example) "Configure Network Connections..." item
> from the popped up menu and then do a left click at any place in the Panel
> (even at the Panel which placed at the second screen) then... the "Networks"
> plasmoid appears, as if I do a left click at the Network's icon in the tray.
> Moreover, if I do a right click at the same icon, then press the Esc key,
> then try to do a right click at any place inside of the Panel, then...
> nothing happened. I.e., it looks like the first right click "eats" the
> second one.
I have this behavior in Plasma 9.1 (arch packages), so I guess it is not caused by this patch. I created bug 376277.