Client: [KDE Plasma 5.9] Systray context menu position on screen shifted

[PVince81]

Steps:

1. Start client
2. Right click on tray icon

Expected

Context menu close to the click

Actual

Menu is shifted:

Versions

openSUSE Tumbleweed with Qt 5.9.1 and owncloud-client package 2.3.3~rc2 that bundles Qt 5.6.2:

It might be a Tumbleweed / Qt 5.9.1 specific issue.

On my other computer which has Leap 42.2 the context menu appears at the correct location.

Maybe another Qt to Qt incompatibility ? @guruz
Let me know if you need me to test stuff like compiling older versions / bisecting.

[SamuAlfageme]

@PVince81 I saw this one this morning (on Kubuntu 17.04)! You're fast!

I think it's a Qt issue when trying to open the systray menu before the notifications go away. Then it stays in that location until you restart the client and wait for the notifications to fade. Can you confirm?

[PVince81]

@SamuAlfageme I tried your hints several times, but even if I wait long after the notification, menu is always shifted.

I also tried to open them menu while the notification is there and the menu overlaps a bit. So your potential theory that maybe the menu position calculation is based on notification height doesn't seem to be correct.

[SamuAlfageme]

Without the "tooltip"

With the "tooltip"

[PVince81]

@SamuAlfageme please post Kubuntu's distro Qt version for reference.

[jnweiger]

@SamuAlfageme I can reproduce your glitch on Leap 42.3
Wait for a tooltip to appear on the bottom. Rightclick the owncloud icon
-> the context menu is far up in the air.

Not 100% reproducable though, ...

[guruz]

(Unclear if bug in Kubuntu/KDE or Qt.. probably the former..
maybe not 2.3.3 but 2.3.4 material if we find a workaround)

[es20490446e]

I can reproduce with:

• Manjaro 17.0
• Plasma 5.10.4
• Owncloud Client 2.3.2

[guruz]

@es20490446e thanks, then it's not a regression. Moving to 2.4..

If someone knows people at KDE/Plasma maybe he/she can @-mention them here or find the upstream issue

[es20490446e]

I'll report this to the KDE bug tracker.

[es20490446e]

Reported at:
(https://bugs.kde.org/show_bug.cgi?id=384003)

You will want to subscribe to that report too.

[ogoffart]

Closing this bug as this is an upstream issue.

[dragotin]

I see the same issue on openSUSE Leap 42.3 with Qt 5.6.2 and KDE Plasma 5.8.7 and KDE-Frameworks Version 4.4.138. The context menu appears just somewhere north the icon, ~500 pixels away.

After playing around a bit, I found that this patch

diff --git a/src/gui/owncloudgui.cpp b/src/gui/owncloudgui.cpp
index c8d5cddcd..6e3f6871a 100644
--- a/src/gui/owncloudgui.cpp
+++ b/src/gui/owncloudgui.cpp
@@ -530,7 +530,8 @@ void ownCloudGui::setupContextMenu()
         || desktopSession.contains("plasma")
         || desktopSession.contains("kde");
     QObject *platformMenu = reinterpret_cast<QObject *>(_tray->contextMenu()->platformMenu());
-    if (isKde && platformMenu && platformMenu->metaObject()->className() == QLatin1String("QDBusPlatformMenu")) {
+    const QString className = platformMenu->metaObject()->className();
+    if (isKde && platformMenu &&  className == QLatin1String("SystemTrayMenu") ) { // instead of QLatin1String("QDBusPlatformMenu")
         _workaroundManualVisibility = true;
         _workaroundNoAboutToShowUpdate = true;
     }

fixes the problem.

@ckamm: Can you confirm that this is a viable fix?

[dragotin]

I wonder why we check for the className at all. Are there other platformMenu objects around that can not use the workaround? This name comparison seems to be flacky at best.

[guruz]

Re-opening to track discussion better.
Unfortunately @ckamm is on holiday.

[es20490446e]

Summertime 🏝

[ckamm]

@dragotin For me (with the kdeplatformtheme) the className would also be "SystemTrayMenu" but the workarounds are not needed.

Unfortunately enabling workarounds can lead to regressions: for example manualVisibility depends on aboutToShow/Hide being reliable and we know at least one configuration where it isn't (OSX).

Currently I don't know of any regressions introduced by _workaroundNoAboutToShowUpdate and I expect that's all that's needed in your case (you can try with OWNCLOUD_FORCE_TRAY_NO_ABOUT_TO_SHOW=1 in the regular build - all workarounds have individual env variables to force them on/off). The main issue of this workaround is that tray menus shown to the user can be outdated a couple of seconds.

Since we probably can't pinpoint the exact version at which this workaround becomes unnecessary (it may be the outdated Qt version; EDIT: I see others see the problem with Qt 5.9.1 too) I'd be ok with enabling that workaround generally for KDE sessions. Can you verify that's all that's needed?

[es20490446e]

No longer happening to me with:

• Owncloud Client 2.4.1
• QT Library 5.11.1
• Deepin Desktop 17.1.11

[dragotin]

Ok, same here: With Qt 5.11.1 on openSUSE Tumbleweed (oCC 2.4.1) it is also not happening any more. On my older installation with Qt 5.6.2 it is broken and my workaround above fixes it.

Maybe I add a patch for builds for older SUSE distros when I prepare the package for 2.4.2. THanks.

[ckamm]

Okay, thanks for double checking! :)