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