Bug 416909

Summary: Clicking-and-holding anything on a widget (e.g. scrollbar, hamburger menu) enters widget edit mode
Product: [Plasma] plasmashell Reporter: Wolfgang Bauer <wbauer1>
Component: ContainmentAssignee: Marco Martin <notmart>
Status: RESOLVED INTENTIONAL    
Severity: minor CC: a-development+kdeidentity, bugseforuns, KMonsefi, mariusz.g.mazur, nate, niccolo, plasma-bugs-null, rob.dyck, tomashnyk, ulterno
Priority: HI Keywords: usability
Version First Reported In: 5.17.90   
Target Milestone: 1.0   
Platform: openSUSE   
OS: Linux   
See Also: https://bugs.kde.org/show_bug.cgi?id=439921
https://bugs.kde.org/show_bug.cgi?id=437594
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Wolfgang Bauer 2020-01-29 13:36:17 UTC
SUMMARY
Some applets on the desktop may have scrollbars, e.g. the folderview or notes applet.

STEPS TO REPRODUCE
1. Add a notes or folderview applet to your desktop
2. Make sure the scrollbar appears (e.g. by configuring a folder with a lot of files, or pasting/typing more text than fits into the visible area)
3. Click on a scrollbar arrow and hold the mouse button pressed to scroll continuously

OBSERVED RESULT
The applet switches to edit mode after a few seconds

EXPECTED RESULT
Should continue scrolling without entering edit mode

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 5.17.90
KDE Frameworks Version: 5.66.0
Qt Version: 5.14.0

ADDITIONAL INFORMATION
Comment 1 Nate Graham 2020-01-29 16:11:46 UTC
Heh, whoops.
Comment 2 Patrick Silva 2020-02-09 19:51:04 UTC
On plasma 5.18 beta, after I leave edit mode of Folder View widget, I can scroll
the files list just moving the cursor on the scroll bar.

Operating System: Arch Linux 
KDE Plasma Version: 5.17.90
KDE Frameworks Version: 5.67.0
Qt Version: 5.14.1
Comment 3 Nate Graham 2021-08-29 21:02:29 UTC
Huh, this is like the opposite problem from Bug 439921.
Comment 4 tomashnyk 2022-04-28 12:22:58 UTC
Isn't this the same as https://bugs.kde.org/show_bug.cgi?id=437594 ?
Comment 5 Nate Graham 2022-05-02 18:19:24 UTC
Similar but not identical. Hard to see if they have the same root cause, or it's just a coincidence.
Comment 6 Nate Graham 2023-10-11 20:54:25 UTC
*** Bug 475314 has been marked as a duplicate of this bug. ***
Comment 7 Nate Graham 2024-11-15 21:13:35 UTC
*** Bug 496311 has been marked as a duplicate of this bug. ***
Comment 8 Nate Graham 2025-05-07 16:55:43 UTC
*** Bug 503758 has been marked as a duplicate of this bug. ***
Comment 9 cwo 2025-06-01 08:05:08 UTC
*** Bug 505068 has been marked as a duplicate of this bug. ***
Comment 10 Bug Janitor Service 2025-06-01 09:23:32 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5553
Comment 11 Patrick Silva 2025-06-01 14:44:25 UTC
*** Bug 446335 has been marked as a duplicate of this bug. ***
Comment 12 cwo 2025-06-03 20:38:52 UTC
Git commit 3d9dd7fe1a664b6b4f20523d6c4425eb57dc6b4c by Christoph Wolk.
Committed on 03/06/2025 at 19:20.
Pushed by cwo into branch 'master'.

containmentlayoutmanager: don't enter edit mode without activefocus

ItemContainer enters edit mode on pressAndHold for desktop widgets not
set to immutable. This causes a problem with menus that open on press -
the container will not receive further mouse events that now go to the
menu, so it still considers itself pressed and unmoved the whole time,
and goes into edit mode after a while, exiting the menu. This makes
on-press menus in desktop widgets borderline unusable, and even if the
user manages to be quick enough to activate the desired entry during the
pressAndHold duration, it'll still enter edit mode unless the user also
does a full click on the applet afterward.

We can circumvent this particular case relatively easily by listening to
the container's activefocus changes - the popup opening does not cause
a focusOut event, but it does take activeFocus away from the container,
so if we stop the timer in that case, it works out as it should.

M  +6    -0    components/containmentlayoutmanager/itemcontainer.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/3d9dd7fe1a664b6b4f20523d6c4425eb57dc6b4c
Comment 13 Bug Janitor Service 2025-06-03 21:04:47 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5560
Comment 14 cwo 2025-06-03 22:38:56 UTC
Git commit 8e6b79da5e58622fd27999c85168a616871324b7 by Christoph Wolk.
Committed on 03/06/2025 at 21:04.
Pushed by cwo into branch 'Plasma/6.4'.

containmentlayoutmanager: don't enter edit mode without activefocus

ItemContainer enters edit mode on pressAndHold for desktop widgets not
set to immutable. This causes a problem with menus that open on press -
the container will not receive further mouse events that now go to the
menu, so it still considers itself pressed and unmoved the whole time,
and goes into edit mode after a while, exiting the menu. This makes
on-press menus in desktop widgets borderline unusable, and even if the
user manages to be quick enough to activate the desired entry during the
pressAndHold duration, it'll still enter edit mode unless the user also
does a full click on the applet afterward.

We can circumvent this particular case relatively easily by listening to
the container's activefocus changes - the popup opening does not cause
a focusOut event, but it does take activeFocus away from the container,
so if we stop the timer in that case, it works out as it should.


(cherry picked from commit 3d9dd7fe1a664b6b4f20523d6c4425eb57dc6b4c)

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

M  +6    -0    components/containmentlayoutmanager/itemcontainer.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/8e6b79da5e58622fd27999c85168a616871324b7
Comment 15 Marco Martin 2025-09-24 09:29:37 UTC
testing after the commit everything seems to work as expected
Comment 16 Nate Graham 2025-09-24 14:38:21 UTC
It's not fixed; you have to press-and-hold and not move the pointer for a moment. When you do this over a draggable UI element, the widget enters edit mode and also activates the thing you pressed-and-held on. The Folder View widget is an easy way to test this.
Comment 17 Bug Janitor Service 2025-09-25 09:47:18 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5850
Comment 18 Marco Martin 2025-09-25 12:06:34 UTC
Git commit 1560be8ab509c2a3a30c8381d382d8f9eeee5eb9 by Marco Martin.
Committed on 25/09/2025 at 11:24.
Pushed by mart into branch 'master'.

ContainmentLayoutManager: send recursive mouse release events too

In order to be sure to not leave any hanging mouse event,
such as the folderview rubberband stuck in selection mode,
when we are sending a recursive ungrab, fist send a recursive mouse release
event as well, to make sure any item that might have an internal state
of mouse pressed will reset it
Related: bug 509859

M  +1    -0    components/containmentlayoutmanager/itemcontainer.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/1560be8ab509c2a3a30c8381d382d8f9eeee5eb9
Comment 19 Bug Janitor Service 2025-09-25 12:19:40 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5852
Comment 20 Marco Martin 2025-09-25 12:19:57 UTC
Git commit 9062abed44a43db8aab724425d1730270e7257a5 by Marco Martin.
Committed on 25/09/2025 at 12:19.
Pushed by mart into branch 'Plasma/6.5'.

ContainmentLayoutManager: send recursive mouse release events too

In order to be sure to not leave any hanging mouse event,
such as the folderview rubberband stuck in selection mode,
when we are sending a recursive ungrab, fist send a recursive mouse release
event as well, to make sure any item that might have an internal state
of mouse pressed will reset it
Related: bug 509859


(cherry picked from commit 1560be8ab509c2a3a30c8381d382d8f9eeee5eb9)

1560be8a ContainmentLayoutManager: send recursive mouse release events too

Co-authored-by: Marco Martin <notmart@gmail.com>

M  +1    -0    components/containmentlayoutmanager/itemcontainer.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/9062abed44a43db8aab724425d1730270e7257a5
Comment 21 Marco Martin 2025-09-25 13:22:26 UTC
now it still enters edit mode but every bad interaction like folderview selection rectangle getting stuck is fixed, and works in the way it was designed.

A design change is always possible but this is another discussion, for now the behavior is intentional
Comment 22 Bug Janitor Service 2025-10-08 14:08:40 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/5904