Created attachment 117033 [details] GIF showing the bug When the Dropbox system tray icon is clicked with either mouse button, a menu pops up. Under Plasma 5, the first time the icon is clicked, the menu appears mostly off-screen, with only the top menu entry accessible. Further clicks on the icon show the entire menu. Please see the attached GIF for a demonstration. This happens with the system tray located on a panel at the bottom of the screen, but might not be reproducible with other system tray locations. DropBox developer "samertm" tried to fix this issue on their end, but was only able to get half of the menu to show on the first click. Discussion here, starting on page 3: https://www.dropboxforum.com/t5/Installation-and-desktop-app/dropbox-2018-11-08-amd64-deb-doesn-t-produce-a-dropbox-menu-on/td-p/311824/page/3 According to samertm, "If someone were to update the KDE notifications tray to update the tray menu's dimensions if the menu items change, that would also fix the issue." STEPS TO REPRODUCE 1. Start Dropbox, or exit and restart it if you have already clicked on the icon this session. 2. Click on the Dropbox icon in the system tray. OBSERVED RESULT The menu is mostly off-screen, with only the top item showing (or top 5 items if DropBox version > 64.3.107). EXPECTED RESULT The entire menu should be visible. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE neon User Edition (Bionic) KDE Plasma Version: 5.14.4 KDE Frameworks Version: 5.53.0 Qt Version: 5.11.2
Thanks for filing! For context, Dropbox two tray icon implementations, one that uses QSystemTrayIcon and one that uses libappindicator. I believe this issues happens with the libappindicator icon, which Dropbox will use if libappindicator and libgtk are installed, and org.kde.StatusNotifierWatcher returns true for IsStatusNotifierHostRegistered. Regarding this issue, I believe the problem is that Dropbox only creates the tray menu when the tray is clicked, and there's some race between when KDE figures out the height of the menu to show and when it shows the menu. E.g. on startup, Dropbox may create a menu with 4 items in it. When the user clicks on the Dropbox tray icon, we'll recreate the menu with 8 items in it, and KDE will try to show those 8 items in a menu that only has the height of a menu with 4 items. If Dropbox created the menu more frequently, e.g. once every second, then it's less likely that users will notice this issue because we'll have probably created the menu of the correct height well before they click the tray icon. We aren't doing that because Dropbox leaks memory every time it creates that menu (which we should fix), and we need to fix that bug first. But on KDE's end, if you recalculate the height of the menu every time it changes, that would also fix the issue for Dropbox and potentially other apps. If someone can point me to the code for KDE's default status tray, I can take a crack at it.
We need to find out which of those two modes we're in before progressing. Super lazy quick test is "killall xembedsniproxy" if the icon moves, it was using xembed. If it stays, it was using the SNI.
(In reply to David Edmundson from comment #2) > We need to find out which of those two modes we're in before progressing. > > Super lazy quick test is > > "killall xembedsniproxy" if the icon moves, it was using xembed. If it > stays, it was using the SNI. The icon doesn't move or change in any way with "killall xembedsniproxy".
As Samer Masterson wrote, this issue is caused by late initialization of menu in Dropbox. When user clicks on the icon, then "AboutToShow" signal is send to Dropbox. Due to asynchronous nature of this calls, there is indeed a race condition. KDE renders the menu with old state, at the same time Dropbox is adding new items to the menu. Menu is positioned using top-left corner. When new items are added, menu simply grows t the bottom. On KDE it is a problem, because by default panel is placed on the bottom of the screen. On Ubuntu (or any other desktop with icons on the top) it is less of a problem, because menu has space to grow. Everything is fine until now, this is quite common use case. There problem is on Dropbox side, it should return true if AboutToShow event should result in the menu being updated: Spec: https://github.com/gnustep/libs-dbuskit/blob/master/Bundles/DBusMenu/com.canonical.dbusmenu.xml Dump of method call: > method call time=1571407985.253788 sender=:1.26 -> destination=:1.137 serial=1047 path=/org/ayatana/NotificationItem/dropbox_client_12927/Menu; > interface=com.canonical.dbusmenu; member=AboutToShow > int32 0 > > method return time=1571407985.268242 sender=:1.137 -> destination=:1.26 serial=20 reply_serial=1047 > boolean false It returns false, so KDE does not expect LayoutUpdated and does not wait for it.
Konrad, is this fixed in Plasma 5.18? I'm using Dropbox and I don't see the problem.
It is not fixed. It is possible that this works for you, because: * you opened menu once, second time it works correctly * your panel is located on the top Anyway, this is a bug in Dropbox client (not the first one, second is Bug 378910). The problem is that I don't even know how to report it... I was not able to find any bug tracker, there is only a forum with basically no support for Linux.
Is there any way we can work around the issue on our side?
(In reply to Nate Graham from comment #7) > Is there any way we can work around the issue on our side? Heh... We can add something like this in our code: if (findExcutableForPid(dbus()->senderPid()) == "*dropbox*") { wait, so menu UpdateLayout can proceed in the meantime or something like that } but... we shouldn't, because: * this is a super ugly hack that can impact performance for all right clicks on tray icons * Dropbox is using Qt (PyQt to be clear)! It should work correctly out of the box, they are definitely doing something nasty. Of course everything is compiled and obfuscated, so no chance for community fix. * As Samer Masterson wrote, they have other issue (memory leaks) and that's *their* workaround for it. * I know that Dropbox is important, I'm using it myself. But we shouldn't write costly workarounds for one app. * Dropbox Linux app is buggy and there is no support from their side. I would love to report a bug correct and even send a patch. But I can't * This is not a critical bug that, we can live with that. It is just annying. * I may repeat myself, but it is super ugly :)
Closing, as this is a Dropbox bug.
Fair enough!