Bug 362941 - Java Process Is Unresponsive In System Tray - Jitsi
Summary: Java Process Is Unresponsive In System Tray - Jitsi
Alias: None
Product: plasmashell
Classification: Plasma
Component: XembedSNIProxy (show other bugs)
Version: 5.8.2
Platform: Archlinux Linux
: NOR normal
Target Milestone: 1.0
Assignee: Plasma Bugs List
: 358328 (view as bug list)
Depends on:
Reported: 2016-05-11 12:35 UTC by vindicator
Modified: 2017-05-31 11:39 UTC (History)
37 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.10.1

Screenshot video of problem (690.79 KB, video/ogg)
2016-05-25 11:02 UTC, EMR_Kde
Test case (minimal Java system tray application with code) (6.59 KB, application/gzip)
2016-08-16 15:35 UTC, Maciej Mrozowski
IRC logs, chat with GTK+ developers (6.91 KB, text/plain)
2017-01-17 15:28 UTC, Stormi

Note You need to log in before you can comment on or make changes to this bug.
Description vindicator 2016-05-11 12:35:54 UTC
"Tray icon is not displayed in KDE (5.4.2)" https://github.com/jitsi/jitsi/issues/192
My kded5 version is 5.21.0

The issue seems to be that, with the change of how you handle your system tray, java needs to be notified.

Reproducible: Always

Steps to Reproduce:
1. Install jitsi (https://aur.archlinux.org/packages/jitsi-nightly/ (or just plain jitsi)
2. Make sure settings are such that jitsi minimizes/closes to the system tray
3. Left or Right Mouse Click jitsi icon in System Tray

Actual Results:  
Hover: "JavaEmbeddedFrame" is displayed
Right Mouse Click: No Action
Left Mouse Click: No Action
Left Mouse Double Click: No Action

Expected Results:  
Jitsi window needs to be "restored".

Where does the responsibility lay? KDE, Java, or Jitsi?
Comment 1 vindicator 2016-05-14 08:19:10 UTC
I'll add Gajim as another program not showing in the tray.
Comment 2 kdebugs.anon134 2016-05-25 02:27:42 UTC
I am experiencing EXACLTY the same problem as vindicator@live.com with Jitsi 2.8.5426on openSUSE Leap 42.1.  I installed Jitsi from the Stable Builds repository at:

This is very frustrating because I depend on Jitsi heavily, and KTP is not a suitable replacement, because it lacks SIP support.

My kded5 version is 5.21.0-12.1
Comment 3 EMR_Kde 2016-05-25 10:51:58 UTC
Same thing here with Evolution (evolution-alarm-notify) and Java (davmail, vuze, etc) apps ... they "show up" but you cannot click on them. For example, Pidgin works OK (right-click has context menu, left-click brings the window up).
Comment 4 EMR_Kde 2016-05-25 11:02:54 UTC
Created attachment 99171 [details]
Screenshot video of problem

I click on Pidgin to demonstrate working systray icon. I hover and click on Evolution, and Davmail to show problem with a GTK based and Java based app noted in my comment.
Comment 5 Martin Vuille 2016-07-18 18:59:02 UTC
I think I am running into the same problem with a small java application that creates a tray icon.

On Windows 8.1/Orace JRE 1.8.0_91, tooltip and popup menu are displayed correctly when hovering and right-clicking, respectively.

On KDE (Fedora 23, kded5 version 5.23.0-1)/OpenJDK, hovering displays "JavaEmbeddedFrame" and right-clicking does nothing visible.
Comment 6 David Edmundson 2016-07-21 14:04:25 UTC
*** Bug 358328 has been marked as a duplicate of this bug. ***
Comment 7 Shlomi Fish 2016-07-21 17:23:14 UTC
Adding myself to the CC list after a different bug was marked as this one's duplicate.
Comment 8 Holger 2016-07-25 21:35:01 UTC
To be precise: The Java Process is in no way unresponsive = frozen. It's actually running fine. I'm seeing this with http://tvbrowser.org It will display the normal reminder-dialogs. From such a reminder, you can open the details of the tv-show opening in a second dialog. From there you can configure the left panel and access the settings, from where you can toggle the minimize to tray, which will correctly remove or add the tray-icon on apply. TV-Browser itself is running just fine, only it's tray-icon never gets any mouse events.
Comment 9 Maciej Mrozowski 2016-08-16 15:35:10 UTC
Created attachment 100624 [details]
Test case (minimal Java system tray application with code)

Adding small Java test case.

To execute: $java TrayIconDemo

(rebuild with your jdk if needed)
Comment 10 Jeff Bai 2016-08-24 14:40:55 UTC
(In reply to Maciej Mrozowski from comment #9)
> Created attachment 100624 [details]
> Test case (minimal Java system tray application with code)
> Adding small Java test case.
> To execute: $java TrayIconDemo
> (rebuild with your jdk if needed)

A confirmation here (of it not working of course) ...
Comment 11 Stormi 2016-09-20 20:37:37 UTC
Same issue here in Mageia cauldron and plasma-workspace-5.7.95

This particular issue is flagged release_blocker for the upcoming Mageia 6 release, because most non-KDE programs in the systray can't be interacted with.
Comment 12 Shlomi Fish 2016-10-26 10:31:14 UTC
Hi all!

Any news? That's a pretty serious problem and it affects 5.8.x LTS.
Comment 13 David Edmundson 2016-11-04 22:39:58 UTC
If there's news I'll post in the report. There is no need to ask for updates.

Thanks for that tray demo - the demo code doesn't even show up in wmsystemtray, the code I generally used as a reference - which strongly implies there is something very wrong with that java implmentation.

Do you know where one can find the source for the tray that example is using? As in the lower level java to raw Xlib library.
Comment 14 Stormi 2016-11-04 23:11:08 UTC
Just adding a comment to make sure it has been taken into account that the issue not limited to java applications. It has been reported both in this bug report and in the duplicate bug 358328 various applications that have the same issue:
- easystroke
- gajim
- solaar
- stardict
- radiotray (gtk+3, not gtk+2, which is definitely a lead)

About your "There is no need to ask for updates" comment, as a bug triager for the Mageia distro I totally expect users to ask whether someone is working on the bug they reported every few months. It's part of user / developer interaction. Here it had not been said until your comment that someone was going to have a look. This very bug has been reported first in january (see duplicates older than this one) and is one of the reasons we still haven't been able to release Mageia 6 to the public, since although we are a desktop-agnostic distro, KDE / Plasma is the most used desktop and we can't release with so many applications that can't be interacted with via the system tray. So maybe asking if someone is intending to work on it was not that misplaced after all, or was it?

Anyway, thanks for your intention to diagnose the origin of the bug, be it in XembedSNIProxy or something else.
Comment 15 Faheem Pervez 2016-11-06 17:58:49 UTC
Using neon-devedition-gitunstable-20161105-0806-amd64 with kdeplasma-workspace version 4:5.8.3+p16.04+git20161105.0450-0, I can reproduce this with JDownloader 2 which comes bundled with its own JRE (Java(TM) SE Runtime Environment (build 1.8.0_66-b17)).

I found a bad workaround for JD2, the only program I need XEmbedSNIProxy for:

* set JDownloader 2 to open from the tray with a single click

* rebuild xembed-sni-proxy with the following changes in sniproxy.cpp:

    * in void SNIProxy::Activate(int x, int y), under the sendClick call, add QThread::msleep(500);

    * do the same with void SNIProxy::ContextMenu(int x, int y), but use a delay of 3000

Now I have only three seconds to choose something from the JDownloader context menu, but in my case, that's always the exit option anyway...
Comment 16 Rémi Verschelde 2016-11-14 15:47:51 UTC
May I suggest to rephrase the bug Summary to something more accurate, as this bug report has grown to encompass more than only java applications and/or jitsi.

From a bug triage point of view, you have two options:

- Keep this bug report for java applications only, and rename it to something like "System tray icons for Java applications are not responsive".
Then another bug report should be opened for the GTK+3 applications with unreponsive systray icons that were mentioned below and/or in bug reports that were closed as duplicates of this one.

- Keep this bug report for both java and GTK+3 applications with an unresponsive systray icon, and rename it to something like "System tray icons for Java and GTK+3 applications are not responsive".

Also, the Platform should likely be changed to something more accurate than Archlinux Packages Linux, as there have been enough bug reports from various distros to find out that it's not a distro-specific issue.
Comment 17 Sergio 2016-12-17 12:34:29 UTC
I confirm that the bug is not specific to Arch and completely cross-distro (seen in KUbuntu Xenial with latest KDE backports, that is plasma 5.6.5).

Bug may also affect non-Java application, but the fact that all Javaland apps are still hardly usable in Plasma 5 seems particularly severe.
Comment 18 Sergio 2017-01-05 14:21:10 UTC
Still an issue with 5.8.5, tested with the xenial Kubuntu PPA.
Comment 19 Stormi 2017-01-17 15:28:38 UTC
Created attachment 103464 [details]
IRC logs, chat with GTK+ developers

I got an interesting chat with helpful GTK+ developers on their IRC channel. Logs attached.

It *is* a bug in xembed-sni-proxy in that it sends forged events that GTK+3 don't listen to by default. 

A possible fix would be to have xembed-sni-proxy send both old-style events and newer-style events and let the event mask pick the appropriate one. This way it should work both in GTK2 and GTK3.

An ugly workaround is to start the applications that have a systray icon with GDK_CORE_DEVICE_EVENTS=1 and then it works because it forces the GTK3 application to go back 10 or 15 years back into time and listen to raw X events (if I understood correctly).
Comment 20 Sergio 2017-01-17 19:42:41 UTC
Here, GDK_CORE_DEVICE_EVENTS=1 does not seem to help.



gets the following:

1) Jitsi (that is a java application) starts, icon shows in system tray
2) Icon is unresponsive (does not open the menu when clicked)

tested on Kubuntu 16.10 with kubuntu backports (i.e., plasma 5.8.5)
Comment 21 vindicator 2017-01-17 20:21:54 UTC
OMG Sergio, the goal of GTK is to completely drop system tray icons??? I cannot think of ANY reasoning to do that.
If you have a clock, volume control, or any other manageable indicators in a bar, you have system tray icons.
The whole point of the system tray is for quick view/access of certain types of programs and their status.
I wish he elaborated on what the "change to" would be. I can't find any search results about it, but rather people looking for sni-qt or libindicator (a desire for their programs to be in the system tray).
Not that I have any reason or desire to move back to Gnome, this surely would keep me far away from it.
KDE has completely cinched it for me. Especially within the past few months I guess, where everything is mostly solid (minus java tray icons). Every little bug I encountered is cleared up. While I haven't used Windows-10 much, I'd still stick with Plasma. It's very powerful and customizable.
I probably shouldn't post this comment since it doesn't add to the bug talk, but I thought that IRC statement by ebassi about dropping tray icons is just too huge. If I want to make any validity to posting this, maybe to keep KDE from following suit... ;)
Comment 22 David Edmundson 2017-01-17 21:10:09 UTC

Thanks. That IRC log was really useful.

I'll try synthesising XI events and report back.
Comment 23 Rik Mills 2017-02-01 07:45:56 UTC
I am now seeing this issue with Plasma 5.9.0 for systray icons of Firetray and Hexchat.

Plasma 5.9.0, Frameworks 5.30 & Qt 5.7.1

- Right mouse clicks are ignored. No context menu, and shows: 

"Could not find DBusMenu interface, falling back to calling ContextMenu()"

- Left mouse clicks seem to work normally
Comment 24 David Edmundson 2017-02-17 12:09:26 UTC
@Rik that's something slightly different. should be fixed in 5.9.2
Comment 25 Patrick Silva 2017-03-06 00:37:34 UTC
This bug affects me on Arch.
I hope some fix is near.
Comment 26 David Edmundson 2017-03-24 09:35:52 UTC
Git commit 9df815e843a4385465fff0cb9a76ddc94ed35b38 by David Edmundson.
Committed on 24/03/2017 at 09:35.
Pushed by davidedmundson into branch 'master'.

Inject mouse clicks from SNI to xembedded icons with XTest

A certain toolkit doesn't register for mouse press release events
because it now uses XI2 only.

Injecting those directly to the window is too difficult, fortunately in
the GTK3 case we can use XTest to send an event. Something I had
previously chosen against using because it didn't work with something
else (can't remember what). I now have a bit of code choosing which
method to use, which will hopefully cover all cases.

Code is a bit convuluted because the xcb version of xtest doesn't have
the high-level method I want to use in it's API, so I just used Xlib
Related: bug 375017

Test Plan:
Ran my usual bunch of test apps:
- xchat
- a GTK3 systray demo I made
- skype (A Qt4 app without SNI patches)

All worked as before

Reviewers: #plasma

Subscribers: plasma-devel

Tags: #plasma

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

M  +3    -3    xembed-sni-proxy/CMakeLists.txt
M  +26   -2    xembed-sni-proxy/sniproxy.cpp
M  +7    -0    xembed-sni-proxy/sniproxy.h
A  +32   -0    xembed-sni-proxy/xtestsender.cpp     [License: LGPL (v2.1+)]
A  +28   -0    xembed-sni-proxy/xtestsender.h     [License: LGPL (v2.1+)]

Comment 27 David Edmundson 2017-03-27 10:03:57 UTC
It's maybe fixed with that last commit.
Comment 28 Rémi Verschelde 2017-03-27 18:58:39 UTC
Nice work David, thanks!

I've cherry-picked the patch for Mageia's plasma-workspace 5.8.6 package, we will report back once it has been tested.

Note that you should probably edit the CMakeLists.txt to make XTest/xtst a required dependency, otherwise plasma-workspace fails building:

[ 98%] Building CXX object xembed-sni-proxy/CMakeFiles/xembedsniproxy.dir/xtestsender.cpp.o
/home/iurt/rpmbuild/BUILD/plasma-workspace-5.8.6/xembed-sni-proxy/xtestsender.cpp:21:34: fatal error: X11/extensions/XTest.h: No such file or directory
compilation terminated.
Comment 29 Nicolas L. 2017-03-28 09:23:17 UTC
I just tested this patch on mageia with plasma 5.8.6 and still nothing with a right click.

when right clicking i have :

Could not find DBusMenu interface, falling back to calling ContextMenu()

in the terminal
Comment 30 Nicolas L. 2017-03-28 09:28:28 UTC
BTW, you can add easystroke on your test apps, here it does not work ( gtk3 app )
Comment 31 David Edmundson 2017-03-28 10:40:17 UTC
That message should be there.
Comment 32 Wolfgang Bauer 2017-03-28 13:07:01 UTC
Well, the fix seems to work for GTK3 applications, i.e. for those where  the GDK_CORE_DEVICE_EVENTS=1 worked too (tested with Audacious).

It doesn't work for Java applications though, tested with tvbrowser.
There GDK_CORE_DEVICE_EVENTS=1 doesn't help either.
(java still uses GTK2 btw AFAICT...)
Comment 33 Wolfgang Bauer 2017-03-30 12:23:24 UTC
PS: At least, the XTest method seems to work fine with Java applications too.
I changed the commit to use it unconditionally, and tvbrowser does react to mouse clicks now.

So maybe the check can be "improved" so that XTest is being used for Java applications as well...
Comment 34 Andreas Kilgus 2017-05-29 07:11:55 UTC
(In reply to Wolfgang Bauer from comment #33)
> PS: At least, the XTest method seems to work fine with Java applications too.
> I changed the commit to use it unconditionally, and tvbrowser does react to
> mouse clicks now.
> So maybe the check can be "improved" so that XTest is being used for Java
> applications as well...

Hm, so the solution or at least the way to go seems to be known. It's a good thing to have GTK3 applications working again in systray, but since this bug report is about Java applications ...

Unfortunately neither release notes of 5.8.7 nor 5.10 mention any changes concerning systray+Java.

@David: Ping? ;-)
Comment 35 Wolfgang Bauer 2017-05-31 10:54:26 UTC
I noticed that the check when to use XTest was broken, so the previous "fix" was completely ineffective.

This fixes it for me:

PS: I made a mistake regarding audacious. Only the mouse wheel worked, left and right-clicks did not (unless I set GDK_CORE_DEVICE_EVENTS=1).
Comment 36 Wolfgang Bauer 2017-05-31 11:39:18 UTC
Git commit 7df184afa19f148c1cd09ae9588645bb2b4556fc by Wolfgang Bauer.
Committed on 31/05/2017 at 11:36.
Pushed by wbauer into branch 'Plasma/5.10'.

[xembedsniproxy] Fix check whether to use XTest

Because of C++'s operator precedence, '!' logically negated
all_event_masks only instead of the whole expression.
This resulted in the condition always being false and XTest never being

Adding a pair of brackets fixes it.
Related: bug 375017
FIXED-IN: 5.10.1
Differential Revision: https://phabricator.kde.org/D6048

M  +1    -1    xembed-sni-proxy/sniproxy.cpp