Bug 482222

I can reproduce this issue as described. It seems like a million things are happening at once. Just overall a very glitchy experience. It seems to me that the gestures aren't being exclusively captured by KWin; moving there for further triage.

I checked with WAYLAND_DEBUG, and KWin does grab the touch points, and sends an event cancelling the already-sent touch points, so I'm 99% certain this is a plasmashell (or maybe Qt) bug

*** Bug 483291 has been marked as a duplicate of this bug. ***

Just as an FYI: At least the "selection rectangle being drawn indefinitely" bug seems to have been fixed in 6.0.3.

The only bug that I still experience is edit mode being activated randomly when performing multi-finger touch gestures.

I'm still experiencing the "dragging mode lock-up" (BUG1) on plasma 6.0.3 (archlinux package `plasma-desktop 6.0.3-1`).

---

Here's a bit more on the "randomly entering edit mode" glitch (BUG2); 

STEPS TO REPRODUCE
0. Be on a touchscreen device
1. Activate desktop overview by 3-finger-swipe-up gesture
2. While in overview, 1-finger-tap somewhere on the empty desktop space

EXPECTED RESULT
desktop overview deactivates

OBSERVED RESULT
desktop overview deactivates, and then about a half time, it randomly goes into the panel edit mode. 

---

One more glitch that can be possibly related...? When I tap on some xwayland windows (instead of empty desktop space) it activates right-click context menu (BUG3). 

STEPS TO REPRODUCE
0. Be on a touchscreen device, running plasma 6.0.3, wayland session
1. Run an application on xwayland, I used 
  - google-chrome (123.0.6312.105, Preferred Ozone platform=x11)
  - slack-desktop (4.37.94, not sure about its electron dependency version)
3. Make sure the xwayland window is focused before gesturing
4. Activate desktop overview by 3-finger-swipe-up gesture
5. While in overview, 1-finger-tap to select the xwayland window

EXPECTED RESULT
desktop overview deactivates, the window is focused

OBSERVED RESULT
desktop overview deactivates, the window is focused, then immediately right-click context menu is open always

---

Few notes; 

- BUG3 is not observed when google-chrome is running wayland-native (Preferred Ozone platform=wayland)
- BUG2 is no longer observed once BUG1 is in action 
- As mentioned in the original report, the only way to get rid of BUG1 status I found is to restart plasma, then BUG2 starts to show up again until BUG1 comes back.

*** Bug 486221 has been marked as a duplicate of this bug. ***

I was just about to report this bug (see my entry in KDE Discuss, https://discuss.kde.org/t/3-finger-gestures-on-touchscreen-bug/15956), but found that this is exactly the bug I'm experiencing to a T.

SUMMARY
I’ve found a bug that I can easily replicate on my laptop that flummoxes me: When using 3-finger swipes to switch desktops or open overview on my touchscreen, edit mode is entered (initially) and subsequent attempts to use 3-fingered gestures cause a selection rectangle to be opened on my desktop (wherever the mouse is positioned). 
Note that this is NOT an issue with touchpad gestures (flawless), just my touchscreen.

STEPS TO REPRODUCE
1. Use 3-finger gestures on the touchscreen → forcibly enter edit mode.
2. Exit edit mode, try to use gestures again → edit mode this time is not entered, but a selection rectangle is permanently shown on the desktop which follows the mouse (even without pressing either mouse button).
   - Notably, once this selection rectangle is present, 3-finger gestures on the touchscreen are flawless.
3. The only way to remove this selection rectangle is to either log out or to use the selection rectangle to actually select something on the desktop. This does remove it, however…
4. Once the selection rectangle is removed, using 3-finger gestures on the touchscreen begins step #1 all over again.

OBSERVED RESULT
- 3-finger gestures on touchscreen cause edit mode and a persistent selection box that follows the mouse.

EXPECTED RESULT
- (Only) switch virtual desktops, open overview/grid view.

SOFTWARE/OS VERSIONS
- Wayland session
- Plasma: 6.0.4
- KDE framework: 6.2.0
- Qt version: 6.7.0
- OS: Arch Linux, 6.9.1 kernel

HARDWARE
- T480s ThinkPad
- CPU: Intel i5-8th gen
- GPU: Intel Mesa UHD 620
- RAM: 16GB

ADDITIONAL INFORMATION
At least one other user has been able to replicate this problem (https://discuss.kde.org/t/3-finger-gestures-on-touchscreen-bug/15956). Notably both instances are using Lenovo touchscreen laptops.
I am additionally using 150% fractional scaling, but I suspect this is irrelevant.

Can also confirm this with my Pinetab 2

KDE Plasma Version: 6.0.4
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.0

Arch Linux ARM

I can also confirm this bug on my Asus ROG flow x13 GV301QH
I additionally observed that using the gestures while firefox is in foreground will also cause issues inside of firefox. For example Youtube player UI never disappearing or UI elements being permanently highlighted.

KDE Plasma Version: 6.0.5
KDE Frameworks Version: 6.2.0
Qt Version: 6.7.1

Arch Linux

*** Bug 488284 has been marked as a duplicate of this bug. ***

Bug Condition Update:

(Full discussion at https://discuss.kde.org/t/3-finger-gestures-on-touchscreen-bug/15956/2)

I have noticed this bug is only present when attempting to use 3-finger gestures on a bare desktop background, and is NOT present when a gesture is started on top of an application window or even the task manager (tricky to pull off on a small touchscreen :D)! 

Can confirm the bug is still 100% present when used on any blank desktop wallpaper areas, and no changes as far as I can see. This is simply me noticing the bug is only present in more specific circumstances than I was previously aware.

Can anyone else reproduce this behaviour? It would be awesome to narrow the bug constraints down a little further!

(In reply to Cameron Smith from comment #11)
> Bug Condition Update:
> 
> (Full discussion at
> https://discuss.kde.org/t/3-finger-gestures-on-touchscreen-bug/15956/2)
> 
> I have noticed this bug is only present when attempting to use 3-finger
> gestures on a bare desktop background, and is NOT present when a gesture is
> started on top of an application window or even the task manager (tricky to
> pull off on a small touchscreen :D)! 
> 
> Can confirm the bug is still 100% present when used on any blank desktop
> wallpaper areas, and no changes as far as I can see. This is simply me
> noticing the bug is only present in more specific circumstances than I was
> previously aware.
> 
> Can anyone else reproduce this behaviour? It would be awesome to narrow the
> bug constraints down a little further!

Yeah I can reproduce it too

I have now done some testing within firefox and it seems that an appropriate TOUCHCANCEL is fired when the 3 finger gesture activates.
It seems that sites like youtube do not recognize this touchcancel and still carry on with the touch input.

So I guess inside of applications (at least firefox) this is handled correctly.

Created attachment 170831 [details]
Touch gestures trigger edit mode

Comment on attachment 170831 [details]
Touch gestures trigger edit mode

I was about to open a bug when I saw this report. I will attach it here anyhow. 

OBSERVED RESULT
Edit mode is activated.

EXPECTED RESULT
A long press with one finger should probably trigger a right-click, as it is what usually happens with other software (although that does not appear to be the case in the rest of the kde programs).
Three-finger swipe should not trigger edit mode  because it is used to switch workspaces and to activate overview.
Furthermore, a gesture should not trigger edit mode in any case, because there are only so many of them available to the user, and I don't think we should waste them with edit mode, which is something you will probably use once as you set up and then rarely afterwards. 

SOFTWARE/OS VERSIONS

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.5-200.fc40.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 7530U with Radeon Graphics
Memory: 5.6 GiB of RAM
Graphics Processor: AMD Radeon Graphics
Manufacturer: LENOVO
Product Name: 83B2
System Version: Yoga 6 13ABR8

ADDITIONAL INFORMATION
Touch device used is:
Input driver version is 1.0.1
Input device ID: bus 0x18 vendor 0x56a product 0x52fa version 0x100
Input device name: "Wacom HID 52FA Finger"
Supported events:
  Event type 0 (EV_SYN)
  Event type 1 (EV_KEY)
    Event code 330 (BTN_TOUCH)
  Event type 3 (EV_ABS)
    Event code 0 (ABS_X)
      Value   8107
      Min        0
      Max    11440
      Resolution      40
    Event code 1 (ABS_Y)
      Value   3343
      Min        0
      Max     7152
      Resolution      40
    Event code 47 (ABS_MT_SLOT)
      Value      1
      Min        0
      Max        9
    Event code 53 (ABS_MT_POSITION_X)
      Value      0
      Min        0
      Max    11440
      Resolution      40
    Event code 54 (ABS_MT_POSITION_Y)
      Value      0
      Min        0
      Max     7152
      Resolution      40
    Event code 57 (ABS_MT_TRACKING_ID)
      Value      0
      Min        0
      Max    65535
  Event type 4 (EV_MSC)
    Event code 5 (MSC_TIMESTAMP)
Properties:
  Property type 1 (INPUT_PROP_DIRECT)

For more information:

(BUG1) Dragging mode lockup
(BUG2) EditMode bug


Possible fix (BUG1) Dragging mode lockup

Source: https://github.com/KDE/plasma-desktop/raw/master/containments/desktop/package/contents/ui/FolderView.qml
--------------------------------------------------------------------------------------
--- FolderView.qml	2024-06-25 11:14:10.000000000 -0600
+++ FolderView-patch.qml	2024-06-28 18:09:03.977260395 -0600
@@ -243,7 +243,8 @@
                 : (Qt.LeftButton | Qt.RightButton);
         }
 
-        hoverEnabled: true
+        hoverEnabled: false
+        // hoverEnabled: true
 
         onPressXChanged: {
             cPress = mapToItem(gridView.contentItem, pressX, pressY);
--------------------------------------------------------------------------------------

Possible fix (BUG2) EditMode bug     

Note: Touchscreen long press doesnt open EditMode. Other ways EditMode works, for example context menu or key shortcuts.
             
Source: https://github.com/KDE/plasma-desktop/raw/master/containments/desktop/package/contents/ui/main.qml
--------------------------------------------------------------------------------------
--- main.qml	2024-06-25 11:14:10.000000000 -0600
+++ main-patch.qml	2024-06-28 17:50:03.305023347 -0600
@@ -309,7 +309,8 @@
             containmentItem: root
             editModeCondition: Plasmoid.immutable
                     ? ContainmentLayoutManager.AppletsLayout.Locked
-                    : ContainmentLayoutManager.AppletsLayout.AfterPressAndHold
+                    : ContainmentLayoutManager.AppletsLayout.Manual
+            //        : ContainmentLayoutManager.AppletsLayout.AfterPressAndHold
 
             // Sets the containment in edit mode when we go in edit mode as well
             onEditModeChanged: Plasmoid.containment.corona.editMode = editMode;
@@ -327,7 +328,8 @@
 
                 editModeCondition: Plasmoid.immutable
                     ? ContainmentLayoutManager.ItemContainer.Locked
-                    : ContainmentLayoutManager.ItemContainer.AfterPressAndHold
+                    : ContainmentLayoutManager.ItemContainer.Manual
+                //    : ContainmentLayoutManager.ItemContainer.AfterPressAndHold
 
                 configOverlaySource: "ConfigOverlay.qml"
--------------------------------------------------------------------------------------

*** Bug 490418 has been marked as a duplicate of this bug. ***

*** Bug 489844 has been marked as a duplicate of this bug. ***

i can reproduce, and wrong things happen with both the basic desktop and folderview conainments, with folderview having much more serious symptoms.

I'll concentrate a bit more on the basic desktop at first, since the folderview layer is "contained" in the basic desktop code.

what i see happening is if i start a gesture with 3 fingers, then no matter how short i keep the fingers on screen, the deskotp will always go in edit mode, which indeed looks like events not properly cancelled

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4652

Git commit 96787a7c0c6489592e5facefc20a5e4ce898712d by Marco Martin.
Committed on 30/08/2024 at 12:36.
Pushed by mart into branch 'master'.

Fixes for touchscreen interaction

* Manage TouchCancel
* Only support press and hold with exactly one touchpoint
Doesn't fully fix the bug but mitigates it, it needs some changes in plasma-desktop as well for a full fix

M  +11   -1    components/containmentlayoutmanager/appletslayout.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/96787a7c0c6489592e5facefc20a5e4ce898712d

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4662

Git commit f3e61b78b089af472c9c87a4a78ca098eca77884 by Marco Martin.
Committed on 30/08/2024 at 14:06.
Pushed by mart into branch 'Plasma/6.1'.

Fixes for touchscreen interaction

* Manage TouchCancel
* Only support press and hold with exactly one touchpoint
Doesn't fully fix the bug but mitigates it, it needs some changes in plasma-desktop as well for a full fix


(cherry picked from commit 96787a7c0c6489592e5facefc20a5e4ce898712d)

M  +11   -1    components/containmentlayoutmanager/appletslayout.cpp

https://invent.kde.org/plasma/plasma-workspace/-/commit/f3e61b78b089af472c9c87a4a78ca098eca77884

That fixes the issues on the KDE side. Some additional fixes are needed in Qt, which have been submitted with https://codereview.qt-project.org/c/qt/qtwayland/+/581714 and are under active review!