[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 --- Comment #10 from Nate Graham --- Fair enough! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 Konrad Materka changed: What|Removed |Added Resolution|--- |DOWNSTREAM Status|REPORTED|RESOLVED --- Comment #9 from Konrad Materka --- Closing, as this is a Dropbox bug. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392
--- Comment #8 from Konrad Materka ---
(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 :)
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 --- Comment #7 from Nate Graham --- Is there any way we can work around the issue on our side? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 --- Comment #6 from Konrad Materka --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 --- Comment #5 from Nate Graham --- Konrad, is this fixed in Plasma 5.18? I'm using Dropbox and I don't see the problem. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 Konrad Materka changed: What|Removed |Added CC||mate...@gmail.com --- Comment #4 from Konrad Materka --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 Nate Graham changed: What|Removed |Added CC||n...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 S. Christian Collins changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #3 from S. Christian Collins --- (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". -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 David Edmundson changed: What|Removed |Added Resolution|--- |WAITINGFORINFO Status|REPORTED|NEEDSINFO CC||k...@davidedmundson.co.uk --- Comment #2 from David Edmundson --- 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. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 402392] dropbox system tray menu positioned off-screen
https://bugs.kde.org/show_bug.cgi?id=402392 Samer Masterson changed: What|Removed |Added CC||sa...@samertm.com --- Comment #1 from Samer Masterson --- 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. -- You are receiving this mail because: You are watching all bug changes.
