plasmashell 5.9.5, Wayland. At desktop, right click the folder, or widget. there will be a popmenu, such as `configure desktop`. when you left click other area, the origin popmenu still exists.
*** Bug 381125 has been marked as a duplicate of this bug. ***
*** Bug 382765 has been marked as a duplicate of this bug. ***
*** Bug 383485 has been marked as a duplicate of this bug. ***
*** Bug 383487 has been marked as a duplicate of this bug. ***
*** Bug 385784 has been marked as a duplicate of this bug. ***
*** Bug 386298 has been marked as a duplicate of this bug. ***
*** Bug 387526 has been marked as a duplicate of this bug. ***
plasma 5.12 stable has the same bug on Arch Linux.
Bug persists in plasma 5.13 beta. Context menu of icons in desktop remains open if I click on desktop background or press ESC. The same happens with the context menu of any element in plasma panel (icon in system tray, task manager entry, pinned app icon, widget). If I click on some window instead on desktop background, the conext menu is closed.
what Qt version?
qt 5.11 rc2 on Arch Linux, qt 5.10 on neon dev unstable.
Same as Chapatin. If I click the desktop or switch virtual desktops, the menu remains. If I click an application, it disappears. I'm on Manjaro testing with Plasma 5.13.2 and Qt 5.11.1.
*** Bug 398566 has been marked as a duplicate of this bug. ***
Not sure if I understood correctly what is the patch from bug #398566 (as it has no context lines at all) but the patch that I tried improves situation but doesn't completely resolve it. diff --git a/popup_input_filter.cpp b/popup_input_filter.cpp index fc74540ed..c9e93c559 100644 --- a/popup_input_filter.cpp +++ b/popup_input_filter.cpp @@ -65,13 +65,9 @@ bool PopupInputFilter::pointerEvent(QMouseEvent *event, quint32 nativeButton) // filter out this press return true; } - if (pointerFocus && pointerFocus->isDecorated()) { - // test whether it is on the decoration - const QRect clientRect = QRect(pointerFocus->clientPos(), pointerFocus->clientSize()).translated(pointerFocus->pos()); - if (!clientRect.contains(event->globalPos())) { - cancelPopups(); - return true; - } + if (!m_popupClients.contains(pointerFocus)) { + cancelPopups(); + return true; } } return false;
(In reply to Andrius Štikonas from comment #14) > Not sure if I understood correctly what is the patch from bug #398566 (as it > has no context lines at all) but the patch that I tried improves situation > but doesn't completely resolve it. > > diff --git a/popup_input_filter.cpp b/popup_input_filter.cpp > index fc74540ed..c9e93c559 100644 > --- a/popup_input_filter.cpp > +++ b/popup_input_filter.cpp > @@ -65,13 +65,9 @@ bool PopupInputFilter::pointerEvent(QMouseEvent *event, > quint32 nativeButton) > // filter out this press > return true; > } > - if (pointerFocus && pointerFocus->isDecorated()) { > - // test whether it is on the decoration > - const QRect clientRect = QRect(pointerFocus->clientPos(), > pointerFocus->clientSize()).translated(pointerFocus->pos()); > - if (!clientRect.contains(event->globalPos())) { > - cancelPopups(); > - return true; > - } > + if (!m_popupClients.contains(pointerFocus)) { > + cancelPopups(); > + return true; > } > } > return false; Sorry, I just noticed the lines are specified there. I'll try that patch again.
Well, even with full patch, popups don't work as well as on X11. I sometimes still can open both popup at window titlebar and taskbar simultaneously. Also if I open popup on chromium (via XWayland) titlebar and then right click on the webpage, I can see both kwin popup menu and chromium popup menu simultaneously. Nevertheless, it feels better than without this patch.
Awesome, wanna submit that patch for review?
(In reply to Nate Graham from comment #17) > Awesome, wanna submit that patch for review? See Roman's comment https://phabricator.kde.org/D15480#325325
Darn.
(In reply to Nate Graham from comment #19) > Darn. To make it slightly less, darn, this patch seems to break some minor things too (sometimes popup doesn't open when it should), it wasn't perfect anyway.
(In reply to Andrius Štikonas from comment #20) > To make it slightly less, darn, this patch seems to break some minor things > too (sometimes popup doesn't open when it should), it wasn't perfect anyway. When exactly?
(In reply to Vlad Zagorodniy from comment #21) > (In reply to Andrius Štikonas from comment #20) > > To make it slightly less, darn, this patch seems to break some minor things > > too (sometimes popup doesn't open when it should), it wasn't perfect anyway. > > When exactly? 1) Right click on the desktop. 2) Press Ctrl+F2 (to switch to another Virtual desktop) 3) Right click on Plasma panel, popup doesn't open
(In reply to Andrius Štikonas from comment #22) > (In reply to Vlad Zagorodniy from comment #21) > > (In reply to Andrius Štikonas from comment #20) > > > To make it slightly less, darn, this patch seems to break some minor things > > > too (sometimes popup doesn't open when it should), it wasn't perfect anyway. > > > > When exactly? > > 1) Right click on the desktop. > 2) Press Ctrl+F2 (to switch to another Virtual desktop) > 3) Right click on Plasma panel, popup doesn't open Ok, I partially take it back. It's not a regression of the patch. It seems to be another issue which is present even without your patch.
(In reply to Andrius Štikonas from comment #22) > (In reply to Vlad Zagorodniy from comment #21) > > (In reply to Andrius Štikonas from comment #20) > > > To make it slightly less, darn, this patch seems to break some minor things > > > too (sometimes popup doesn't open when it should), it wasn't perfect anyway. > > > > When exactly? > > 1) Right click on the desktop. > 2) Press Ctrl+F2 (to switch to another Virtual desktop) > 3) Right click on Plasma panel, popup doesn't open Opened another bug for this issue https://bugs.kde.org/show_bug.cgi?id=398628.
*** Bug 377123 has been marked as a duplicate of this bug. ***
Bug persists. Operating System: Arch Linux KDE Plasma Version: 5.14.0 Qt Version: 5.11.2 KDE Frameworks Version: 5.50.0
bug persists in plasma 5.15 beta :( Operating System: Arch Linux KDE Plasma Version: 5.14.90 KDE Frameworks Version: 5.54.0 Qt Version: 5.12.0
This bug persists with plasma 5.16 beta. Operating System: Arch Linux KDE Plasma Version: 5.15.90 KDE Frameworks Version: 5.58.0 Qt Version: 5.13.0 beta3
This bug does persist, but only with folders, not widgets (at least not with analog clock) Operating System: Arch Linux KDE Plasma Version: 5.15.90 KDE Frameworks Version: 5.58.0 Qt Version: 5.13.0 beta3
*** Bug 411683 has been marked as a duplicate of this bug. ***
Context menu of window decoration is also affected. Operating System: Arch Linux KDE Plasma Version: 5.17.90 KDE Frameworks Version: 5.66.0 Qt Version: 5.14.0
*** Bug 383904 has been marked as a duplicate of this bug. ***
*** Bug 417082 has been marked as a duplicate of this bug. ***
*** Bug 418415 has been marked as a duplicate of this bug. ***
I've recently noticed that the bug only occurs if the desktop is in "Desktop" mode (i.e. no icons on the desktop), it does not happen if the desktop is in "Folder view" mode (with icons on the desktop).
(In reply to tromzy from comment #35) > I've recently noticed that the bug only occurs if the desktop is in > "Desktop" mode (i.e. no icons on the desktop), it does not happen if the > desktop is in "Folder view" mode (with icons on the desktop). The bug is also visible on other Plasma surfaces (e.g. taskbar), I don't think this would be affected by the desktop mode. In any case, Vlad has a reproducer app that he attached to Qt bug.
Thanks for adding a reference to that Qt bug, Vlad. Is this purely an upstream issue, or something we can work around on the KDE side?
*** Bug 422966 has been marked as a duplicate of this bug. ***
*** Bug 426654 has been marked as a duplicate of this bug. ***
*** Bug 426993 has been marked as a duplicate of this bug. ***
Tons and tons of dupes, and this becomes more obvious as Wayland gains users due to its improved stability these days. Raising priority.
*** Bug 426991 has been marked as a duplicate of this bug. ***
Is this purely a Qt issue that we need to wait for a fix for, or is there anything we can do on the Plasma or KWin side?
Git commit 6689abaffb076515085f2912028a1e3e3deaf36f by Vlad Zahorodnii. Committed on 02/10/2020 at 16:42. Pushed by vladz into branch 'master'. [Shell Corona] Work around popup dismissal bug on Wayland A popup needs to grab the keyboard and the pointer in order to dismiss itself when another window is clicked. It works perfectly on X11. On Wayland though, the compositor is responsible for dismissing popups if some surface of another application has been clicked. Note that I said "of another application." If user clicks some surface of the same application, the compositor won't dismiss the popup. If the application uses only QtWidgets, then the popup will be closed as expected in both cases. But if the application uses both Qt Quick and Qt Widgets, e.g. plasmashell, then the popup won't be dismissed if a QQuickItem has been clicked. It is a Qt bug, but for the time being, this change introduces an event filter that monitors Qt::MouseButtonPress events and when needed closes the active popup widget. This is a workaround. M +95 -0 shell/shellcorona.cpp https://invent.kde.org/plasma/plasma-workspace/commit/6689abaffb076515085f2912028a1e3e3deaf36f
Git commit 329db2a68c6e70722bce7058af8b5ec31238b07b by Vlad Zahorodnii. Committed on 02/10/2020 at 16:44. Pushed by vladz into branch 'Plasma/5.20'. [Shell Corona] Work around popup dismissal bug on Wayland A popup needs to grab the keyboard and the pointer in order to dismiss itself when another window is clicked. It works perfectly on X11. On Wayland though, the compositor is responsible for dismissing popups if some surface of another application has been clicked. Note that I said "of another application." If user clicks some surface of the same application, the compositor won't dismiss the popup. If the application uses only QtWidgets, then the popup will be closed as expected in both cases. But if the application uses both Qt Quick and Qt Widgets, e.g. plasmashell, then the popup won't be dismissed if a QQuickItem has been clicked. It is a Qt bug, but for the time being, this change introduces an event filter that monitors Qt::MouseButtonPress events and when needed closes the active popup widget. This is a workaround. (cherry picked from commit 6689abaffb076515085f2912028a1e3e3deaf36f) M +95 -0 shell/shellcorona.cpp https://invent.kde.org/plasma/plasma-workspace/commit/329db2a68c6e70722bce7058af8b5ec31238b07b
If from a user perspective the problem is effectively fixed now, should this bug report be closed?
>If from a user perspective the problem is effectively fixed now, should this bug report be closed? If a bug exists and a user doesn't see it.. sounds like the start of a philosophical question. In general /a/ report needs to stay open so we can eventually do things properly. In this case we do have the upstream report. I think that will suffice.
(In reply to David Edmundson from comment #47) > >If from a user perspective the problem is effectively fixed now, should this bug report be closed? > > If a bug exists and a user doesn't see it.. sounds like the start of a > philosophical question. > If I understand correctly, this was a workaround in plasmashell. Are there any other apps that we ship that are affected by that Qt bug?
Context menu of window decoration is still affected after this workaround.
>Are there any other apps that we ship that are affected by that Qt bug? Not many, it requires both QtQuick with QWidget context menus.
(In reply to Patrick Silva from comment #49) > Context menu of window decoration is still affected after this workaround. I can reproduce that but not reliably (happens maybe 50% of time if I right-click on window decoration and then right click on desktop).
*** Bug 426741 has been marked as a duplicate of this bug. ***