Bug 505718 - When scrolling down Folder View widget, clicking on items activates the wrong ones
Summary: When scrolling down Folder View widget, clicking on items activates the wrong...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Desktop icons & Folder View widget (other bugs)
Version First Reported In: 6.4.0
Platform: Neon Linux
: VHI major
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: regression
: 505933 506180 (view as bug list)
Depends on:
Blocks:
 
Reported: 2025-06-18 00:10 UTC by Alberto Mattea
Modified: 2025-06-25 19:11 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.4.1
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alberto Mattea 2025-06-18 00:10:01 UTC
SUMMARY
When a folder view widget (either in the panel or in the desktop) is scrolled down, clicking on icons no longer works.

STEPS TO REPRODUCE
1. Add a folder view widget, point it to a folder with enough content to need scrolling
2. Scroll down
3. Click on any icon

OBSERVED RESULT
Nothing happens

EXPECTED RESULT
The element associated with the icon gets opened/launched

SOFTWARE/OS VERSIONS
Neon User Edition
KDE Plasma Version: 6.4.0
KDE Frameworks Version: 6.15.0
Qt Version: 6.9.0

ADDITIONAL INFORMATION
This started happening after the upgrade to Plasma 6.4, it worked fine in 6.3
Comment 1 Nate Graham 2025-06-18 15:10:23 UTC
Can confirm in both icon view and list view.
Comment 2 Nate Graham 2025-06-18 15:23:36 UTC
 I bisected plasma-desktop and found that it was caused by this commit:

commit 53d67b9a0b82fff40b2057f1ceb74b529b943df5 (HEAD)
Author: Christoph Wolk <cwo.kde@posteo.net>
Date:   Mon May 26 12:17:04 2025 +0200

    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.
    
    BUG: 504765

 containments/desktop/package/contents/ui/FolderView.qml | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)
Comment 3 Nate Graham 2025-06-18 15:24:23 UTC
Christoph, could I ask you to take a look at this?
Comment 4 Bug Janitor Service 2025-06-18 17:57:06 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/3075
Comment 5 cwo 2025-06-20 16:25:20 UTC
Git commit dbd2551e3097433b838facf4045c67427069a581 by Christoph Wolk.
Committed on 20/06/2025 at 16:25.
Pushed by cwo into branch 'master'.

containments/desktop: fix folder view clicking

53d67b9a0b82fff40b2057f1ceb74b529b943df5 made clicking use the same
logic to determine the selected item for mouse and touch, rather than
relying on hover events. It seems the logic for touch was broken in some
cirumstances, namely scrolled views and certain alignments, where the
coordinate systems do not align.

A similar issue was already fixed elsewhere in folder view with
509b655ef2edef04a13d9afaab6349911beaaeb1, so we reuse the approach here.
Related: bug 497498, bug 504569
FIXED-IN: 6.4.1

----

Would be good if someone could test if this works with touch, as I don't have a functional touch device handy. Might be that this was also broken there (couldn't find a bug report there though) or doesn't apply.

M  +2    -1    containments/desktop/package/contents/ui/FolderView.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/dbd2551e3097433b838facf4045c67427069a581
Comment 6 cwo 2025-06-20 17:58:43 UTC
Git commit f6c6e03a5fed3435ea47605e232af57140625440 by Christoph Wolk.
Committed on 20/06/2025 at 16:25.
Pushed by cwo into branch 'Plasma/6.4'.

containments/desktop: fix folder view clicking

53d67b9a0b82fff40b2057f1ceb74b529b943df5 made clicking use the same
logic to determine the selected item for mouse and touch, rather than
relying on hover events. It seems the logic for touch was broken in some
cirumstances, namely scrolled views and certain alignments, where the
coordinate systems do not align.

A similar issue was already fixed elsewhere in folder view with
509b655ef2edef04a13d9afaab6349911beaaeb1, so we reuse the approach here.
Related: bug 497498, bug 504569
FIXED-IN: 6.4.1

----

Would be good if someone could test if this works with touch, as I don't have a functional touch device handy. Might be that this was also broken there (couldn't find a bug report there though) or doesn't apply.


(cherry picked from commit dbd2551e3097433b838facf4045c67427069a581)

4445acf7 containments/desktop: fix folder view clicking

Co-authored-by: Christoph Wolk <cwo.kde@posteo.net>

M  +2    -1    containments/desktop/package/contents/ui/FolderView.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/f6c6e03a5fed3435ea47605e232af57140625440
Comment 7 TraceyC 2025-06-20 19:43:16 UTC
(In reply to cwo from comment #6)
> 
> Would be good if someone could test if this works with touch, as I don't
> have a functional touch device handy. Might be that this was also broken
> there (couldn't find a bug report there though) or doesn't apply.

I tested this on a touchscreen laptop, and verified this bug cannot be reproduced, and the Folder View works as expected.
Comment 8 cwo 2025-06-21 22:15:13 UTC
*** Bug 505933 has been marked as a duplicate of this bug. ***
Comment 9 Nate Graham 2025-06-25 19:11:37 UTC
*** Bug 506180 has been marked as a duplicate of this bug. ***