Bug 378910

Summary: System Tray forgets Dropbox hidden state after logout+login
Product: [Plasma] plasmashell Reporter: Jonathan Verner <jonathan.verner>
Component: System TrayAssignee: Konrad Materka <materka>
Status: RESOLVED FIXED    
Severity: normal CC: dsjstc, kde, KDE, materka, nate
Priority: NOR Keywords: usability
Version: 5.9.4   
Target Milestone: 1.0   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed In: 5.22.0
Sentry Crash Report:

Description Jonathan Verner 2017-04-18 09:20:41 UTC
For some applications (notably the dropbox client) System Tray forgets the "hidden" setting on logout. E.g. I set the state of the Dropbox entry to "Hidden", but when I logout and login again, the Dropbox entry is in the "Auto" state. Note that other applications (even third party ones, like e.g. MegaSync) remember their state fine.

This bug is probably a duplicate of Bug #158986, but that one was reported against the ancient KDE 3 version so I filed a new bug rather than commenting on the old one. I am not sure what the correct procedure is, though...
Comment 1 Nate Graham 2018-05-26 14:11:28 UTC

*** This bug has been marked as a duplicate of bug 361614 ***
Comment 2 Nate Graham 2018-05-26 22:59:53 UTC
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.
Comment 3 Nate Graham 2018-05-26 23:05:33 UTC
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.
Comment 4 Nate Graham 2018-10-08 19:42:48 UTC
*** Bug 399520 has been marked as a duplicate of this bug. ***
Comment 5 Konrad Materka 2019-10-16 11:03:10 UTC
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...
Comment 6 Nate Graham 2019-10-16 16:48:27 UTC
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.
Comment 7 Nate Graham 2019-12-11 08:55:10 UTC
Maybe we could just match on the executable name itself?
Comment 8 Konrad Materka 2019-12-12 10:47:37 UTC
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.
Comment 9 Nate Graham 2019-12-12 11:59:00 UTC
Are you sure the executable name isn't available? Can we make it available somehow? Is that possible?
Comment 10 David Edmundson 2019-12-12 14:46:50 UTC
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();
Comment 11 Konrad Materka 2019-12-12 21:55:16 UTC
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.
Comment 12 Michal Kec (MiK) 2021-02-20 09:30:25 UTC
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?
Comment 13 Nate Graham 2021-02-20 14:27:27 UTC
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?
Comment 14 Konrad Materka 2021-03-06 15:48:06 UTC
I will prepare a workaround
Comment 15 Bug Janitor Service 2021-03-06 15:56:35 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/699
Comment 16 Konrad Materka 2021-03-07 11:31:33 UTC
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