STEPS TO REPRODUCE 1. Place several apps in autostart (~/.config/autostart). I have Telegram, Discord, Charm timetracker, GoldenDict. The apps themselves seem do not really matter. 2. Restart Plasma. OBSERVED RESULT On Plasma startup, not all the apps are always have icons in systray. EXPECTED RESULT All the apps should have systray icons. Operating System: Ubuntu 20.04 KDE Plasma Version: 5.19.80 KDE Frameworks Version: 5.74.0 Qt Version: 5.14.2 ADDITIONAL INFORMATION Independent of X11/Wayland
Which ones don't? Does it change after every reboot, or is it consistent?
It happens randomly, all of these apps had icon absent one run or another. So I think it's app irrelevant. It seems racy, maybe amount of the icons does matter. Have you tried reproduce it Nate?
PS: apps themselves do run, only it's icons could absent.
It works for me, but I tend to disable the system tray items for all apps that make it configurable, so I only typically have two (Element and Discord) and I haven't seen it happen with them.
I'll retest with fewer icons to see if it makes any difference. Also I probably should inspect Plasma logs first but to my shame I still don't know where to look for them :)
Please also check Bug 420635, it has some lengthy discussion how to debug it. My guess is that applications are started before StatusNotifierHost, which listens for icons registrations. Please also test on fresh user, just to check if this is not user specific configuration issue. I won't be available for next two weeks, so can't help now, but I will try later.
Created attachment 131994 [details] Script to list all registered SNI @Andrey, please run attached script after restart, when some of the icons are not there. It list all registered icons, so it is expected not to see missing application. Then restart missing apps (kill them and start again), icons should appear (visually and in the output of the script). Please attach outputs. Let's keep Bug 420635 closed, comments there are too messy.
Created attachment 131995 [details] listIcons.sh output Here what listIcons.sh reports before and after missing Telegram icon was restored by the app restart
BTW, I have relatively slow PC, maybe that is why the bug reproduces for me easily.
(In reply to Andrey from comment #9) Thank you for logs, I can see that icon for Telegram was not registered at all, which is not good but at least we can rule out problems with rendering. > BTW, I have relatively slow PC, maybe that is why the bug reproduces for me > easily. Yes, looks like a common denominator - in similar bug there was a faulty HDD, which slowed down the whole system. There is definitely a race condition... Unfortunately I need more information to find out what was run and (more importantly) in which order... When it happens again, please run listIcons.sh again, and also check logs: > journalctl -b 0 | grep StatusNotifier and get some statistics of Telegram (if icon for Telegram is missing): > pidof Telegram | xargs -I '{}' ps -hp "{}" -o pid,start,command
Created attachment 132014 [details] ./listIcons.sh output again (In reply to Konrad Materka from comment #10) > (In reply to Andrey from comment #9) > Thank you for logs > ... > There is definitely a race condition... No problem, glad it confirmed. > When it happens again, please run listIcons.sh again, attached. > and also check logs: > > journalctl -b 0 | grep StatusNotifier got no output here > and get some statistics of Telegram (if icon for Telegram is missing): > > pidof Telegram | xargs -I '{}' ps -hp "{}" -o pid,start,command 48435 00:08:53 /var/home/bam/Telegram/Telegram -autostart
(In reply to Andrey from comment #11) > > and also check logs: > > > journalctl -b 0 | grep StatusNotifier > got no output here This is strange... Do you have any output with: journalctl | grep StatusNotifier If it is possible, can you send whole log? journalctl > log Be warned, log may contain personal information or other sensitive data! Make sure to check and filter out unwanted information. If you want to limit recipients you can check "CC List" in this bug and send using email (if you are willing to do so). > > and get some statistics of Telegram (if icon for Telegram is missing): > > > pidof Telegram | xargs -I '{}' ps -hp "{}" -o pid,start,command > 48435 00:08:53 /var/home/bam/Telegram/Telegram -autostart It is whole 8 seconds after kded5, but I can see that whole plasma startup process takes more that a minute! So it might be that kded5 started, but the service responsible for SNI (Status Notifier Manager) was still loading... Can you share your computer spec (cpu speed/memory/hdd type etc)? Maybe I can simulate it in Virtual Machine.
(In reply to Konrad Materka from comment #12) > Maybe I can simulate it in Virtual Machine. Konrad, one of the reasons of sluggishness on start might be I run Plasma from within Toolbox: https://github.com/containers/toolbox#dependencies-and-installation It should be fairly trivial to repeat, would you like to try? Anyway, will post other details later.
UPDATE: seems the issue is more often reproduces on Wayland, and is not necessary depends on PC speed. I could reproduce it on far more powerful modern PC easily. Could you try on the same set of apps as in OP?
*** Bug 427326 has been marked as a duplicate of this bug. ***
About https://bugs.kde.org/show_bug.cgi?id=427326 Somehow it is not the problem anymore: https://github.com/telegramdesktop/tdesktop/issues/8708#issuecomment-716164808
I'm not sure how Bug 427326 is related TBH. This bug is about the icons don't show up completely, not their right-click menus. And I personally didn't faced with the problem described.
Not sure if this is the same issue, but what happens to me is that after network restart (systemctl restart NetworkManager.service), system tray icon for network sometimes disappears. I have set it to be always shown. When I change visibility to disabled and the back to always shown, icon appears. I have Plasma 5.20.2/ KF 5.75.0/ Qt 5.15.1.
(In reply to elman from comment #18) > Not sure if this is the same issue, but what happens to me is that after > network restart (systemctl restart NetworkManager.service), system tray icon > for network sometimes disappears. I have set it to be always shown. When I > change visibility to disabled and the back to always shown, icon appears. This is different issue, please report it separately. This issue is only about autostart after login, not activation on service start/restart.
*** Bug 420635 has been marked as a duplicate of this bug. ***
*** Bug 385828 has been marked as a duplicate of this bug. ***
Tried to do following change in p-w, nothing has changed: diff --git a/statusnotifierwatcher/statusnotifierwatcher.desktop b/statusnotifierwatcher/statusnotifierwatcher.desktop index e54b06cc8..8d72f483f 100644 --- a/statusnotifierwatcher/statusnotifierwatcher.desktop +++ b/statusnotifierwatcher/statusnotifierwatcher.desktop @@ -128,5 +128,5 @@ X-KDE-ServiceTypes=KDEDModule X-KDE-Library=statusnotifierwatcher X-KDE-Kded-autoload=true X-KDE-Kded-load-on-demand=false -X-KDE-Kded-phase=1 +X-KDE-Kded-phase=0
PS: I'm using systemd plasma startup now, the issue is still there
(In reply to Konrad Materka from comment #12) > journalctl | grep StatusNotifier > If it is possible, can you send whole log? Attaching the log. Relevant line might be: авг 17 21:02:56 Feedme dbus-daemon[2055]: apparmor="DENIED" operation="dbus_signal" bus="session" path="/StatusNotifierWatcher" interface="org.kde.StatusNotifierWatcher" member="StatusNotifierHostRegistered" name=":1.28" mask="receive" pid=2353 label="snap.telegram-desktop.telegram-desktop" peer_pid=2225 peer_label="unconfined"
Created attachment 140801 [details] journalctl -b, no Telegram icon Might be related with Telegram Snap packaging.
PS: still have no issue with Gnome
Created attachment 140802 [details] dbus-monitor --pcap
From the logs: :1.230 is telegram It makes a DBus call to kded asking if we have any SNI hosts (i.e the system tray) KDED is up and ready and available and the call to the SNI watcher works. But there are no hosts as plasma isn't up yet so it returns false We later emit that a host is registered, but at this point telegram doesn't care. From a plasma side that looks like everything is working correctly. Other than moving app restore until after plasma is fully up, there's not much we can do.
I opened upstream issue: https://github.com/telegramdesktop/tdesktop/issues/16833
Telegram maintainers say the fixing Snap issue is controversial upstream and is unlikely to ever be fixed there, so it's effectively our fault for not enforcing that Plasma/the System Tray has to be fully up before apps with tray icons are restored. Perhaps we need to do this in plasmashell, now that we have the ability to control what launches when and which things depend on other things. We can enforce that auto-started apps depend on plasmashell being fully launched. Here are the relevant upstream bugs we can reference for the code to implement this workaround: * https://github.com/telegramdesktop/tdesktop/issues/16833 * https://forum.snapcraft.io/t/statusnotifierhostregistered-dbus-signal-is-not-allowed-thus-broken-tray-support-on-kde-plasma/26091/3
I wonder if we have some performance benefits maybe of having SNI host deferred start? Or it's completely indifferent?
Problem began to continue in the latest KDE version over and over again and with the same applications. Please fix!!!
(In reply to Aleksey Kontsevich from comment #32) > Problem began to continue in the latest KDE version over and over again and > with the same applications. Please fix!!! What kind of apps you have the problem with? - Please make sure they are not Snapped first. - Then, if it's Qt or Electron apps, they apparently don't follow the SNI "Spec" we invented, so to push things forward maybe it worth to start with filing respective issues in those toolkits, and then possibly implement it there: > And I think you still filed bug report in wrong place, tray implementation is inside of Qt and it doesn't support appearing tray host on the fly. > So, either KDE should 'moving app restore until after plasma is fully up' or Qt should rewrite its tray implementation. > https://github.com/qt/qtbase/blob/5.15/src/platformsupport/themes/genericunix/qgenericunixthemes.cpp#L104-L115 See conversation with Telegram devs for details: https://github.com/telegramdesktop/tdesktop/issues/16833#issuecomment-901117407
Applications are: - KeepassXC (Qt) - KShutdown (KDE) So they follow SNI, happens very often.
(In reply to Aleksey Kontsevich from comment #35) > Applications are: > - KeepassXC (Qt) > - KShutdown (KDE) > So they follow SNI, happens very often. Apps with pure Qt SNI implementation are presumably not following our SNI spec, please see what I've wrote above carefully. About KShutdown I don't know, might be a new problem. Can someone confirm this?
I have all entries disabled in system tray and use it only for app indicators (e.g. steam, discord, my mail app etc). I set them all to "always hidden", so i only want to see the arrow in my tray. The mentioned apps all have autostart desktop files in ~/.config/autostart, so i expect the arrow to be shown from the beginning. However it is often missing, and only shows up after i manually start an app with an app indicator. After that it works fine, all the applications started with autostart are in it when i open it. Is this the same bug / root cause?
(In reply to Linus Dierheimer from comment #37) > However it is often missing, and only shows up after i manually start an app with an app indicator. After that it works fine Same for me: after app restart icon is shown. > Is this the same bug / root cause? Seems so.
No i didn't mean that i have to restart the app, i need to start another app with an indicator for the system tray to show them. For example i have discord and my mail program in autostart, the arrow is missing, so i can't see there icons. I start steam, which has an app indicator too, the arrow appears, all app indicators visible when i open it.
(In reply to Linus Dierheimer from comment #37) > Is this the same bug / root cause? This is a different issue. Bug here is for the case when icon is not registered at all. You bug is about missing expanded arrow, which appears after state is changed (in your case - by starting new app). Please file a separate bug report.
I'm facing this issue with only one app in autostart (telegram-desktop). It happens only on Wayland. The machine is relatively modern, so the problem is not related to a slow system. Following my config: Distro: openSUSE Tumbleweed DE: KDE Plasma 5.24.3 Display server: Wayland Qt: 5.15.2 KDE Frameworks: 5.92.0 Kernel: Linux 5.16.14-1-default
(In reply to Roger from comment #41) > I'm facing this issue with only one app in autostart (telegram-desktop). It If you telegram is Snapped, please see discussion above.
(In reply to Andrey from comment #42) > (In reply to Roger from comment #41) > > I'm facing this issue with only one app in autostart (telegram-desktop). It > If you telegram is Snapped, please see discussion above. I have it installed from the openSUSE Main Repository (OSS). See info below: Information for package telegram-desktop: ----------------------------------------- Repository : Main Repository (OSS) Name : telegram-desktop Version : 3.6.0-1.1 Arch : x86_64 Vendor : openSUSE Installed Size : 79,9 MiB Installed : Yes Status : up-to-date Source package : telegram-desktop-3.6.0-1.1.src Upstream URL : https://github.com/telegramdesktop/tdesktop Summary : Messaging application with a focus on speed and security Description : Telegram is a non-profit cloud-based instant messaging service. Users can send messages and exchange photos, videos, stickers, audio and files of any type. Its client-side code is open-source software but the source code for recent versions is not always immediately published, whereas its server-side code is closed-source and proprietary. The service also provides APIs to independent developers.
*** Bug 455150 has been marked as a duplicate of this bug. ***
I do have this issue since the last update on X11. Discord, Linphone, Telegram, KeepassXc and other applications don't have an tray-icon anymore. Don't know if it's act in the same range of the bug, but e.g KeepassXC is incredible slow after last kde-upgrade. # My Environment: Operating System: Manjaro Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.4 Kernel Version: 5.15.48-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-3610QM CPU @ 2.30GHz Memory: 15.1 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4000
Solved it for me by renaming ~/.config and reboot. Then I'd need to move the config-directories to the new created ~/.config for the Applications I do use. Removing plasma* files didn't solve it, think at least the issue where somewhere with a kwin setting file, but couldn't figure out exactly what it was.
I have this only in Wayland and only with Telegram. I use the binary downloaded from their web page: https://telegram.org/dl/desktop/linux (not Flatpak or Snap)
(In reply to David de Cos from comment #47) > I have this only in Wayland and only with Telegram. I use the binary > downloaded from their web page: > https://telegram.org/dl/desktop/linux (not Flatpak or Snap) It happens with X11 as well mostly when we have many apps started on session restore. Sometimes happens with KeePassXC, KShutdown, etc. Recent time very rarely however.
This is caused by a Qt issue: https://bugreports.qt.io/browse/QTBUG-94871 However there may be something we can do to work around it in Plasma code
*** Bug 457676 has been marked as a duplicate of this bug. ***
Raising priority due to number of duplicates.
TL;DR Qt's architecture is complicated in order to fallback to XEMBED when SNI is not available, since it's an architectural issue in Qt, it may be they never would fix the architecture to allow switching the backends on the fly (as needs a lot of work). Since they don't switch on the fly, the effect is if SNI host is started after application is started, the tray icon is blurry on X11 and doesn't show at all on Wayland (as there's nowhere to fallback). As Discord is mentioned in this bug, it may be that Electron has a similar issue. So it may be way easier to ensure that applications are started after all services like SNI host, global menu service, xsettingsd (Qt reads XSETTINGS and doesn't handle when it appears after Qt initialization, just like with SNI/global menu), kwin (https://bugreports.qt.io/browse/QTBUG-95338) and etc, rather than fixing all bugs in all toolkits. That's where Qt decides to use SNI or not: https://github.com/qt/qtbase/blob/a8e6a0e546a6a90ff2daee79c3cf504b7160cb86/src/gui/platform/unix/qgenericunixthemes.cpp#L71-L101 It's called by createPlatformSystemTrayIcon() down this file. If it's not available, it returns nullptr. Every other platform has built-in platformtheme and has windowing system-based tray backend returned by createPlatformSystemTrayIcon() therefore. But X11 is different. They replace entire private QSystemTrayIcon class implementation for it: https://github.com/qt/qtbase/blob/a8e6a0e546a6a90ff2daee79c3cf504b7160cb86/src/widgets/CMakeLists.txt#L825-L833 So it tries to call createPlatformSystemTrayIcon() and creates X11 window right in the private class: https://github.com/qt/qtbase/blob/a8e6a0e546a6a90ff2daee79c3cf504b7160cb86/src/widgets/util/qsystemtrayicon_x11.cpp#L186-L217
I have a similar issue with qBittorrent (https://github.com/qbittorrent/qBittorrent/issues/17499) on Fedora 36. When auto-started qBittorrent shows up before the panel and never gets the system tray icon. qBittorrent is built with qt6 in Fedora 36 repos, rebuilding it with qt5 solves the issue. Mine is also specific to wayland.
The Qt 5 version uses plasma-integration plugin installed by KDE apparently, so KSNI is used instead of QDBusTrayIcon, KSNI has such a hack to behave correctly on KDE: https://github.com/KDE/knotifications/blob/04dbd954e946b1aa540641df7ec69a30f34cc404/src/kstatusnotifieritem.cpp#L984 That fact masks the problem in any application using system Qt 5. AppImages, snaps and sometimes even flatpaks (when Qt from KDE runtime is not used) based on Qt 5 are still affected though.
My problem happens only with telegram-desktop on Arch, which also uses qt6. Other apps, including discord_arch_electron, steam and ktorrent, don't have any problems (except Discord is blurry without libappindicator-gtk3). I use X11 and my problem is not that icons are sometimes not shown, but they have wrong monochrome color and the contours are thinner. I installed qbittorrent for test, it uses qt6 here too. The icon appears every time and it's not ugly and always colored even if I select to use monochrome icons in the app's settings. Also, both torrents don't appear in ~/.config/autostart/
It still fails. In my case with Telegram Desktop app. Operating System: Arch Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.1.7-native_amd-xanmod1-1 (64-bit) Graphics Platform: Wayland Processors: 64 × AMD Ryzen Threadripper 3970X 32-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series Manufacturer: ASUS
I just recently updated my system where the Plasma version is 5.26.5 and now I have the two applications (RSS Guard and MEGAsync) that I have set to startup and has system tray icons not have the system tray icons be present in the applet. I was able to get them back by restarting the applications.
I started having this issue with element-desktop. It doesn't show tray icon and when I try to launch it, it says there is another instance running. So, I kill the autostarted instance and run it again and everything runs fine for that boot. But same story next boot.
Chromium & Electron seem to finally migrated out of appindicator. Chromium's own SNI item support seem to behave just like Qt's one: it does all the checks on start and is not capable to switch backend later on the fly. It seems knotifications' SNI implementation is only one fully compliant nowadays, everyone else cuts the corners on watching for available API changes once application i started up. And it's totally understandable from my PoV, e.g. Qt wouldn't be able to become compliant without architectural changes, X11 and D-Bus implementations are in different modules currently (D-Bus one is in Qt GUI, X11 one is in Qt Widgets). It also seems no other system (Windows, macOS) require applications to set up watchers when using their tray API, so I guess Qt and Chromium won't have much interest in changing their architecture to become compliant... Unless Plasma developers want to develop & push fixes for every toolkit. https://github.com/chromium/chromium/blob/main/chrome/browser/ui/views/status_icons/status_icon_linux_wrapper.cc https://github.com/chromium/chromium/blob/main/chrome/browser/ui/views/status_icons/status_icon_linux_dbus.cc
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/2569
I added a revert of https://github.com/qt/qtbase/commit/23e9b57e3d261f66168a8a28ccb8e5c886b4841f to tdesktop Qt patchset, so it's possible to test whether ignoring StatusNotifierHost helps, in all official builds since version 4.5.9.
I can confirm this bug on fresh user after reinstalling system. On stable 5.26.5 and on testing 5.27 Im using this workaround: bash -c 'sleep 30 && kotatogram-desktop -startintray -- %u'
Any feedback about the state of the bug on tdesktop 4.6 (if installed via official builds)?
Git commit fd9bedc7d76bd7c8987acf625265eb4cdefb9aff by David Edmundson, on behalf of David Redondo. Committed on 07/02/2023 at 16:31. Pushed by ngraham into branch 'master'. StatusNotifierWatcher: Always claim there is a StatusNotifierHost This is of course conceptually wrong. But toolkits may have to provide a static check if the system tray is available or to switch the used backend at startup. This includes for example Qt (when not using our platform theme) or Electron. Pragmatically it makes no difference on Plasma as any Xembed fallback would also not show up in a non-existent system tray. The applications just make one DBus call more if the setup of the user doesn't include any system tray. FIXED-IN:5.27 M +1 -14 statusnotifierwatcher/statusnotifierwatcher.cpp M +1 -2 statusnotifierwatcher/statusnotifierwatcher.h https://invent.kde.org/plasma/plasma-workspace/commit/fd9bedc7d76bd7c8987acf625265eb4cdefb9aff
Git commit 80b479a54e545b42e8f871c269614d94f6b2fe4d by Nate Graham, on behalf of David Redondo. Committed on 07/02/2023 at 17:13. Pushed by ngraham into branch 'Plasma/5.27'. StatusNotifierWatcher: Always claim there is a StatusNotifierHost This is of course conceptually wrong. But toolkits may have to provide a static check if the system tray is available or to switch the used backend at startup. This includes for example Qt (when not using our platform theme) or Electron. Pragmatically it makes no difference on Plasma as any Xembed fallback would also not show up in a non-existent system tray. The applications just make one DBus call more if the setup of the user doesn't include any system tray. FIXED-IN:5.27 (cherry picked from commit fd9bedc7d76bd7c8987acf625265eb4cdefb9aff) M +1 -14 statusnotifierwatcher/statusnotifierwatcher.cpp M +1 -2 statusnotifierwatcher/statusnotifierwatcher.h https://invent.kde.org/plasma/plasma-workspace/commit/80b479a54e545b42e8f871c269614d94f6b2fe4d
This bug seems to have reappeared some time during the 5.27 cycle. I'm on 5.27.4 now and have been noticing it for a while (wasn't there during early versions of 5.27 though). I'm on Wayland if that matters. In addition to affected apps not showing up in the systray, global menu is also broken for them until restarted.
*** Bug 469755 has been marked as a duplicate of this bug. ***
*** Bug 470325 has been marked as a duplicate of this bug. ***
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kded/-/merge_requests/41
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/3301
Git commit 83cabf353b0e33626cf98a0cf4baab94e82dc1a7 by David Edmundson. Committed on 18/09/2023 at 17:00. Pushed by davidedmundson into branch 'master'. Avoid race on startup dispatching DBus methods Since mid-Qt5 DBus is processed on another thread, this will return an error directly if a path is not registered at the time of handling a request. This introduces a lot of new races. We need to have our spy hook registered early. This is safe to do before KDED::self is created as the implementation will post an event to the main thread. M +6 -2 src/kded.cpp https://invent.kde.org/frameworks/kded/-/commit/83cabf353b0e33626cf98a0cf4baab94e82dc1a7
Git commit a5fec18c596c7708e3092efecba329c0f19bb91f by David Edmundson. Committed on 18/09/2023 at 12:43. Pushed by davidedmundson into branch 'master'. Register plugin's DBus service names before the main name There is a hook to allow service names to be registered before plugins are loaded, but in order to be race-free we need to have this done before KDED is announced as up. M +3 -3 src/kded.cpp https://invent.kde.org/frameworks/kded/-/commit/a5fec18c596c7708e3092efecba329c0f19bb91f
Will this land in 5.27?
Possibly; backporting is under discussion. In the meantime, we think there's a solid chance this has fixed the issue. We can't be 100% sure because the issue is difficult to reproduce. But it's our best shot for now. For now if people can test with Plasma 6, that would be ideal!
Any clue if this also fixes bug 466248 ?
Almost certainly. Thanks for following up on that!
*** Bug 466248 has been marked as a duplicate of this bug. ***
Git commit f03ea121200a4b394b5d7af8831861091db0fd7e by Fushan Wen, on behalf of David Edmundson. Committed on 29/09/2023 at 08:11. Pushed by fusionfuture into branch 'master'. statusnotifierwatcher: Use KDED's mechanism for service name announcement KDED has a mechansim to register service names on behalf of a plugin. This is important as kded announces it's up before loading the plugins. M +0 -3 statusnotifierwatcher/statusnotifierwatcher.cpp M +2 -1 statusnotifierwatcher/statusnotifierwatcher.json https://invent.kde.org/plasma/plasma-workspace/-/commit/f03ea121200a4b394b5d7af8831861091db0fd7e