Created attachment 181728 [details] No pointer movement + Right-Clicking = Wrong subsequent Context Menu. 1- Have two items on the Desktop. 2- Right-Click on one of them to open the context menu. 3- Right-Click on the second item in order to close the Context Menu of the other file. 4- Without moving the pointer, Right-Click on the second item in order to open its Context Menu. Result: The Desktop's Context Menu appears because the pointer didn't move before Right-Clicking. Expected result: The item's Context Menu should appear because the pointer is right on top of it. PS: Also happens on Dolphin. PS2: If you use open the inline history on Firefox's hamburger menu, and click on a scrollable site (Ex: KDE Bug List) while the pointer is over the the website area of the browser and don't move your pointer, you're not able to scroll. Could the Context Menu and Firefox's Inline History have the same properties and Plasma for some reason requires pointer movement after closing these things?
Should I report this on QT instead? In theory this issue would have affected QTBUG-134223, but I don't know if this was the reason why it was closed.
I can reproduce the issue for Folder View. Dolphin works as expected and opens the correct menu though.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3020
Git commit 53d67b9a0b82fff40b2057f1ceb74b529b943df5 by Christoph Wolk. Committed on 26/05/2025 at 17:22. Pushed by cwo into branch 'master'. containments/desktop: redetermine item on click In case of touch events, Folder View already resets the hovered item to the actual click position, as touch does not cause hover events. There is another case where a click on a non-hovered element can happen, namely if the containsMouse determination is blocked by an open context menu. If the user does not move the pointer after opening a context menu, moving the pointer to another item, and closing the context menu, left-clicking will leave the icon completely unaffected and right- clicking will re-open the previous context menu, rather than open the one for the clicked entry. Instead, always take the delegate that was clicked to activate or open the context menu, whether on touch or not. This matches the behavior in Dolphin, where in the same situation the hover feedback is not updated, but clicking still works normally. M +11 -8 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/53d67b9a0b82fff40b2057f1ceb74b529b943df5
Git commit 53bd4d6b9f85e1c9962fa30c703c462b4b3e1a13 by Christoph Wolk. Committed on 27/05/2025 at 10:05. Pushed by cwo into branch 'Plasma/6.4'. containments/desktop: redetermine item on click In case of touch events, Folder View already resets the hovered item to the actual click position, as touch does not cause hover events. There is another case where a click on a non-hovered element can happen, namely if the containsMouse determination is blocked by an open context menu. If the user does not move the pointer after opening a context menu, moving the pointer to another item, and closing the context menu, left-clicking will leave the icon completely unaffected and right- clicking will re-open the previous context menu, rather than open the one for the clicked entry. Instead, always take the delegate that was clicked to activate or open the context menu, whether on touch or not. This matches the behavior in Dolphin, where in the same situation the hover feedback is not updated, but clicking still works normally. (cherry picked from commit 53d67b9a0b82fff40b2057f1ceb74b529b943df5) Co-authored-by: Christoph Wolk <cwo.kde@posteo.net> M +11 -8 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/53bd4d6b9f85e1c9962fa30c703c462b4b3e1a13
*** Bug 516437 has been marked as a duplicate of this bug. ***
I still have this bug in Plasma 6.7.4
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3940
Git commit af1d5612caae27db6a19cfa197ae643551803f02 by Christoph Wolk. Committed on 13/08/2026 at 06:35. Pushed by cwo into branch 'master'. containments/desktop: accept right click without hoveredItem The FolderView MouseEventListener, for the FolderView desktop style, only accepts right mouse button when there is a hoveredItem. That property is not always set if the mouse is currently hovering an item; in particular not after a context menu closes if we have not moved the mouse yet. This means that right-clicking an item, then dismissing the context menu, then immediately right-clicking it again will open the containment's context menu, not the one for the item we just right- clicked (again). This is not a problem with FolderView applets, because there we always accept right click. So we also accept it for FolderView desktops. We re-check whether something is hovered in the MouseEventListener's handler anyway, and don't accept the event if we're not actually hovering over something, so it gets passed to the containment anyway, even if we're not blocking it through acceptedButtons. FIXED-IN: 6.8.0 M +1 -1 containments/desktop/package/contents/ui/FolderView.qml https://invent.kde.org/plasma/plasma-desktop/-/commit/af1d5612caae27db6a19cfa197ae643551803f02