Bug 425315

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!!!

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

(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

It seems the commit made some kind of regression as now there's a race condition between registering object and service, I'm getting reports that QDBusTrayIcon is unable to register the tray icon with the following message: QDBusTrayIcon encountered a D-Bus error: QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/StatusNotifierWatcher'")

Which means even if a SNI client implementation would monitor the watcher, it will be unable to register the tray icon due to the missing object.

Perhaps something else started triggering it now after almost a year but still looks like the "Use KDED's mechanism for service name announcement" change causes the object to be unregistered when the service is registered

Created attachment 171590 [details]
telegram debug log

As suggested here https://github.com/telegramdesktop/tdesktop/issues/28126#issuecomment-2220457999, there some details about.
Note: I do not run Plasma. My environment is AwesomeWM. Several packages from KDE suite are installed, though. I could spot dolphin, konsole, digikam, okular, gwenview and may be a half a dozen others. 
O/S - Arch Linux with most recent updates
Bug appears on two different computers only in Telegram desktop. Since the particular commit (see the GitHub thread), tray icon at some conditions has disappearing (with no empty gap) and won't return after killing and restarting of telegram-desktop. Only logout then login restores the appearance.
Steps to reproduce:
 1. Start telegram-desktop
 2. Minimize it to tray
 3. Start dolphin file manager and navigate to any directory with pictures
 4. Open any random JPG with gwenview.
Telegram icon immediately vanishes from systray. After closing telegram, ensuring there are no any leftover processes, and starting it again - icon doesn't appear in system tray at all.

Created attachment 171591 [details]
journalctl log

Wait, I thought you're running Plasma? If you're not running Plasma then your tray daemon is unlikely to be from Plasma...

(In reply to Ilya Fedin from comment #84)
> Wait, I thought you're running Plasma? If you're not running Plasma then
> your tray daemon is unlikely to be from Plasma...

Sorry for late reply. I was several days away from Internet.
Yep, definitely. It's native Awesome wibox.widget.systray 

I could only speculate what might cause crash. I start telegram automatically immediately after login. I tried to run various KDE applications, however only dolphin triggers the issue. After some tests... It's enough to open any file in Dolphin (e.g. text file with Kate, or picture with Gwenview) to destroy Telegram icon.

Trace with journalctl shown the following sequence (# - my comments):

===
# starting dolphin
Jul 15 20:20:07 systemd[1580]: Starting KActivityManager Activity manager Service...
.....
Jul 15 20:20:07 systemd[1580]: Started KActivityManager Activity manager Service.
.....
Jul 15 20:20:36 systemd[1580]: Started dbus-:1.2-org.kde.kdeconnect@5.service.
# Open text file with Kate
Jul 15 20:20:46 systemd[1580]: Started dbus-:1.2-org.kde.kded6@8.service.
Jul 15 20:20:46 telegram-desktop[1620473]: QDBusTrayIcon encountered a D-Bus error: QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/StatusNotifierWatcher'")
Jul 15 20:20:46 systemd[1580]: Started Kate - Advanced Text Editor.
===

If I stop dbus-:1.2-org.kde.kded6@8.service (systemctl --user stop dbus-:1.2-org.kde.kded6@8.service), then restart telegram, tray icon has appearing. If I start dolphin again and open file, there a new instance of dbus-:1.2-org.kde.kded6@Y.service starts (where Y is a next number) and telegram icon crashes again.

Now this constantly happens again with Goldendict-ng with Plasma 6.1.5 and 6.2. Icon now shown after login and session restore.

btw I haven't seen this since a long time and I don't use goldendict. Maybe a different app-specific problem this time?

(In reply to Ilya Fedin from comment #87)
> btw I haven't seen this since a long time and I don't use goldendict. Maybe
> a different app-specific problem this time?

Think same problem. It worked fine for a long period, then started again after upgrade to Plasma 6.1.5 and to 6.2 then recently. Goldendict was not updated for months.

(In reply to Aleksey Kontsevich from comment #86)
> Now this constantly happens again with Goldendict-ng with Plasma 6.1.5 and
> 6.2. Icon now shown after login and session restore.

Today Goldendict-ng restored ok today. Hope was one-time issue. Will observe more.

(In reply to Aleksey Kontsevich from comment #89)
> Today Goldendict-ng restored ok today. Hope was one-time issue. Will observe
> more.
Works fine again for me - 2nd try.

The original bug report says, "The apps themselves seem do not really matter". So if it's only GoldenDict that's affected for you now, it's probably a different issue, possibly in the app itself somehow.

So can you mention whether it affects all your apps , or just that one?

(In reply to Nate Graham from comment #93)
> The original bug report says, "The apps themselves seem do not really
> matter". So if it's only GoldenDict that's affected for you now, it's
> probably a different issue, possibly in the app itself somehow.
> 
> So can you mention whether it affects all your apps , or just that one?

Recent time - only this one. However like I said in comment #89 work fine again for me for now.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Works fine for now, sometimes happens with GoldenDict. May be related to bug Bug 491130, or may be GoldenDict not quite stable - freezes. Not sure.

OK. Let's close this bug report, since it seems likely that the issue is subtly different — either a bug in GoldenDict itself, or a different thing going wrong in our code.