Bug 452967 - kwin_wayland: touch input does not reach GTK or Chromium popup menus (subsurfaces)
Summary: kwin_wayland: touch input does not reach GTK or Chromium popup menus (subsurf...
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Unclassified
Component: input (show other bugs)
Version: 5.25.3
Platform: Manjaro Linux
: NOR major (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL: https://gitlab.gnome.org/GNOME/gtk/-/...
Keywords: wayland
Depends on:
Blocks:
 
Reported: 2022-04-25 01:04 UTC by Kevin Kofler
Modified: 2022-08-05 02:43 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.25.5


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Kofler 2022-04-25 01:04:51 UTC
SUMMARY
On Plasma Mobile (which uses kwin_wayland), popup menus in any GTK application do not respond to touch input. Touching any menu entry or any other control in the GTK popover just closes the popup without taking any action.

The same effect can be seen for Chromium popups, including ones from QtWebEngine (though Angelfish ≥ 21.12 has a workaround using QML popups instead, so you will not be able to reproduce the issue with recent versions of Angelfish).

This happens only for touch input using Wayland. Plugging in a USB mouse into the PinePhone and clicking with it works. Forcing the application to use X11 (using GDK_BACKEND=x11 for GTK apps or QT_QPA_PLATFORM=xcb for QtWebEngine apps) also works (sorta, because that causes several other issues such as no virtual keyboard coming up).

This issue makes most GTK applications unusable on Plasma Mobile (e.g., Password Safe cannot be used because you cannot add a new password entry without going through a popup), and reduces the functionality of most of the remaining ones (e.g., in Geary, you cannot autocomplete addresses, switch between plain text and rich text (HTML) composing, etc.), so IMHO it should be treated as a showstopper.

According to GTK developer Carlos Garnacho, the issue is that the GTK popover/popup menu is a subsurface, and kwin_wayland is incorrectly sending the touch event to the main surface instead.

STEPS TO REPRODUCE
As stated above, make sure you are using:
1. Wayland, both in KWin AND in the application (the bug canNOT be reproduced with X11), AND
2. touch (finger) input (the bug canNOT be reproduced with a mouse).
A good device to try it on is a PinePhone running the default Manjaro ARM Plasma Mobile edition.

Once that is set, there are several ways to reproduce the bug, e.g.:
* In Geary, I "click" (touch) Inbox, then the "new message" button, then the "⋮" menu button. The popup menu that results does not work.
* Also in Geary, the autocompletion popup in the "To" field (when I start typing a known address) does not work.
* Password Safe is not usable because the "Add" popup does not work. (I do not remember the exact way to get to it because I uninstalled the application due to being unable to use it because of this bug.)
* To see that this also happens with Chromium/QtWebEngine popups, fire up Angelfish < 21.12, or presumably another QtWebEngine browser that does not have Angelfish's workaround, and try opening https://www.falter.at/lokalfuehrer and using the search filters there (the popups like "ALLE BUNDESLÄNDER").

OBSERVED RESULT
The popup closes without any action being taken.

EXPECTED RESULT
The click on the popup is processed.

SOFTWARE/OS VERSIONS
Manjaro ARM PinePhone Plasma Mobile Edition
Last tested with:
KDE Plasma Version: 5.24.2
KDE Frameworks Version: 5.92.0
Qt Version: 5.15.3 with KDE backports

ADDITIONAL INFORMATION
This longstanding issue was initially reported at:
https://invent.kde.org/plasma/plasma-mobile/-/issues/65
There, it was claimed to be a GTK issue, so:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3737
was filed. Then nothing had happened for months. From a log file I uploaded, GTK developer Carlos Garnacho was able to locate the issue in KWin:
https://gitlab.gnome.org/GNOME/gtk/-/issues/3737#note_1385359
and Vlad Zahorodnii intended to investigate further, but nothing has now happened for 2 months. So I am filing this here now, in the hope that it will finally get the attention of somebody who is able to fix it.
Comment 1 Kevin Kofler 2022-05-16 11:27:32 UTC
Ping? (3 more weeks have passed…) Is there anything more you need from me? (I have already posted GTK Wayland debugging logs that show that the KWin compositor is delivering the events to the wrong surface, see the linked https://gitlab.gnome.org/GNOME/gtk/-/issues/3737#note_1385359 . So, is there more that I can do to help getting this fixed?)
Comment 2 fedorabugreporter88 2022-06-25 17:29:47 UTC
Im having the same issue on Fedora 36 KDE 5.25.1 I had the issue on 5.24 as well. When using a touch screen when I try to press a popup menu on a gtk app it interacts with whatever is under the popup window.  I dont know if you guys are still doing 15 minute bugs but this even effects firefox's hamburger menu meaning if youre a touch screen user it pops up immediately.
Comment 3 Kevin Kofler 2022-06-26 20:26:13 UTC
Well, yes, I am not surprised that this can also be reproduced with a desktop/notebook/tablet with a touch device.

At least, if you are using Plasma Desktop on Fedora KDE, you have the option to switch to an X11 session (pick "Plasma (X11)" instead of "Plasma (Wayland)" in SDDM) to work around this issue. (I am running Plasma Desktop on X11 on Fedora all the time.) That is not really an option on Plasma Mobile.
Comment 4 Culprit8045 2022-07-16 01:29:41 UTC
As of 5.25.3 and KDE Frameworks 5.96, this bug still exists.  I would be happy to help out in any way that I can.
Comment 5 Bug Janitor Service 2022-07-22 13:50:22 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/2700
Comment 6 Aleix Pol 2022-07-29 11:52:44 UTC
Git commit 94ee33e9be132175587a65d02934ed1bbfc96015 by Aleix Pol Gonzalez, on behalf of Aleix Pol.
Committed on 29/07/2022 at 11:39.
Pushed by apol into branch 'master'.

wayland: Fix touch event delivery to subsurfaces

Use SurfaceInterface::inputSurfaceAt when deciding which surface are we
entering when sending a pointer event from a touch, in case it falls
onto a subsurface.

M  +18   -7    src/wayland/seat_interface.cpp
M  +4    -7    src/wayland/touch_interface.cpp
M  +1    -2    src/wayland/touch_interface.h

https://invent.kde.org/plasma/kwin/commit/94ee33e9be132175587a65d02934ed1bbfc96015
Comment 7 Kevin Kofler 2022-07-29 22:18:07 UTC
Can this bugfix be backported to the upcoming 5.25.4 bugfix release?
Comment 8 Kevin Kofler 2022-07-30 10:35:15 UTC
5.25.4 is scheduled for August 4, so there are 5 days left to backport this.

IMHO, this is a critical bugfix and definitely ought to be backported.
Comment 9 Nate Graham 2022-08-01 14:50:09 UTC
It doesn't backport cleanly, so someone smarter than me would have to do it, and make the case that it's safe enough. Can you comment in https://invent.kde.org/plasma/kwin/-/merge_requests/2700?
Comment 10 Kevin Kofler 2022-08-05 02:41:22 UTC
Git commit dccb6f6472ce9dcad259f0b3852896792dfb73b2 by Kevin Kofler, on behalf of Aleix Pol.
Committed on 04/08/2022 at 21:41.
Pushed by kkofler into branch 'Plasma/5.25'.

wayland: Fix touch event delivery to subsurfaces

Use SurfaceInterface::inputSurfaceAt when deciding which surface are we
entering when sending a pointer event from a touch, in case it falls
onto a subsurface.

M  +18   -7    src/wayland/seat_interface.cpp
M  +4    -7    src/wayland/touch_interface.cpp
M  +1    -2    src/wayland/touch_interface.h

https://invent.kde.org/plasma/kwin/commit/dccb6f6472ce9dcad259f0b3852896792dfb73b2