Bug 504765

Summary: Wrong Context Menu appears if the user doesn't move the pointer after the previous one fades out.
Product: [Plasma] plasmashell Reporter: Fernando M. Muniz <fernandommuniz>
Component: Desktop icons & Folder View widgetAssignee: Plasma Bugs List <plasma-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: cwo.kde, hein
Priority: NOR    
Version First Reported In: 6.3.5   
Target Milestone: 1.0   
Platform: Arch Linux   
OS: Linux   
See Also: https://bugzilla.mozilla.org/show_bug.cgi?id=1954768
https://bugs.kde.org/show_bug.cgi?id=504878
https://bugs.kde.org/show_bug.cgi?id=508360
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: No pointer movement + Right-Clicking = Wrong subsequent Context Menu.

Description Fernando M. Muniz 2025-05-25 10:34:32 UTC
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?
Comment 1 Fernando M. Muniz 2025-05-26 05:31:20 UTC
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.
Comment 2 cwo 2025-05-26 07:15:17 UTC
I can reproduce the issue for Folder View.

Dolphin works as expected and opens the correct menu though.
Comment 3 Bug Janitor Service 2025-05-26 10:20:39 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3020
Comment 4 cwo 2025-05-26 20:25:43 UTC
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
Comment 5 cwo 2025-05-27 11:27:20 UTC
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