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

After investigating Bug 361614 further, it looks like that issue is fixed, and this one is a Dropbox-specific problem. I can confirm it myself. Let's use it to track that.

I'm guessing that at least a large part of this problem is related to the fact that the executable name changes:

$ grep hiddenItems ~/.config/plasma-org.kde.plasma.desktop-appletsrc
hiddenItems=org.kde.plasma.mediacontroller,dropbox-client-1764,org.kde.plasma.clipboard,org.kde.plasma.vault,dropbox-client-1447,dropbox-client-3761

Those three entries are the result of three attempts to hide Dropbox. Each attempt succeeds, but then it's un-hidden again after the next login because the executable name has changed due to the number (a PID, maybe?) changing.

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

Yes, Dropbox Id contains PID, which changes with each run. System Tray relies on this Id. Unfortunately, there is no proper fix on KDE side...

Could we maybe define a regex to match on that could exclude the PID? We have a similar override table for misbehaving apps in the task manager. Maybe we should do the same for the system tray.

Maybe we could just match on the executable name itself?

We can't access executable, StatusNotifierItem has no such property. There is only Id and Title, but Title can change at any time, can be translated etc.
I guess the only way is handle this is to use custom regex per app, but I don't like it. Dropbox should be fixed, it is not following the specification:
https://www.freedesktop.org/wiki/Specifications/StatusNotifierItem/StatusNotifierItem/
> org.freedesktop.StatusNotifierItem.Id
> It's a name that should be unique for this application and consistent between sessions, such as the application name itself.

Are you sure the executable name isn't available? Can we make it available somehow? Is that possible?

We can.

We know the DBus service name owner. 
From that we can know the PID

QDBusReply<uint> pidReply = connection().interface()->servicePid(message().service());


From that we can get anything

    auto processInfo = KProcessList::processInfo(pid);

    return processInfo.name();

Will it work correctly with xembedsniproxy?
Dropbox is broken, there is another bug report for context menu - they are not following specification there to. I guess we can implement a workaround, but this should be limited to Dropbox only - by default Id is working well.

The issue is still present with Plasma 5.21 and 116.4.368.

As there's no such problem with another app, would be possible to accept dropbox-only solution mentioned earlier?

I think so. We have app-specific workarounds for LibreOffice in the Task Manager.

It's always preferable to not work around app bugs, but in the case of popular important apps that are either not FOSS, or are FOSS but the problem is virtually unsolvable, sometimes it's needed.

Wanna submit a merge request?

I will prepare a workaround

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/699

Git commit 3dee28974ebf92f078dada44d189c31cc2e1abb7 by Konrad Materka.
Committed on 07/03/2021 at 11:25.
Pushed by kmaterka into branch 'master'.

[applets/systemtray] Add workaround for Dropbox

System Tray forgets Dropbox hidden state after logout+login

The SNI Id should be consistent between sessions, but Dropbox does not
follow the SNI specification - it adds PID as a suffix of Id.

As this is very popular application and it was not fixed upstream for
many years it is reasonable to add workaround in SystemTray.
FIXED-IN: 5.22.0

M  +14   -3    applets/systemtray/systemtraymodel.cpp

https://invent.kde.org/plasma/plasma-workspace/commit/3dee28974ebf92f078dada44d189c31cc2e1abb7