The window cannot be moved by touch #9

New issue

Closed

opened 2026-10-13 03:22:11 +00:00 by asxpi · 0 comments

asxpi commented

2026-10-13 03:22:11 +00:00

Why

Two things are missing, either one enough to stop it:

The page never asks for a move on touch. ui/src/views/window-drag.ts starts a move on mousedown followed by a mousemove with the button held past 4px. WebKitGTK sends no mouse events while a finger drags; it only synthesizes a click when the finger lifts. So frame.startDragging() is never called. A Wayland log of a test session shows no xdg_toplevel.move after any touch, and one after every mouse drag.
tao's move is mouse-only. startDragging() ends in tao 0.35.3's WindowRequest::DragWindow (src/platform_impl/linux/event_loop.rs:336), which calls begin_move_drag(1, x, y, 0) on the seat's pointer device. Started during a touch, GTK would send the move with a mouse serial, and the compositor would refuse it.

What a fix needs

In the page: start the move from pointer events with pointerType === 'touch' (pointerdown, then pointermove past the threshold) on the data-window-drag regions, alongside the mouse path.
In the shell: a command that starts the move for the touchscreen device, e.g. gdk_window_begin_move_drag_for_device() with the device and position of the touch in progress, so the request carries the live touch's serial. Exactly one request per touch.

Careful with mutter

Until mutter has a NULL check in touch_can_grab_surface() (#7), a second move or resize request carrying the serial of a touch that mutter has already cancelled crashes GNOME Shell, and starting a move is what makes mutter cancel the touch. So the shell side must send the request once per touch and never repeat it, and it is best tested on a patched mutter first.

Also seen

With the touch-resize handlers blocked (#8), every finger lift still makes tao's button-press handler (event_loop.rs:521) answer GTK's emulated click with xdg_toplevel.resize(seat, 0 or a stale mouse serial, 1), a top-edge resize. The compositor refuses it and it carries no touch serial, so it is harmless, but it is noise worth reporting to tao along with its touch resizing.

On Linux with the app's own title bar, the window cannot be moved with a finger on a touchscreen: dragging the header bar by touch does nothing. With a mouse it moves as expected. Seen on GNOME (Wayland, mutter 50.2) with the 0.4.7 Flatpak built from `fix/touch-resize` (#8); nothing in that branch touches the move path, so it is most likely the same in every build. ## Why Two things are missing, either one enough to stop it: 1. **The page never asks for a move on touch.** `ui/src/views/window-drag.ts` starts a move on `mousedown` followed by a `mousemove` with the button held past 4px. WebKitGTK sends no mouse events while a finger drags; it only synthesizes a click when the finger lifts. So `frame.startDragging()` is never called. A Wayland log of a test session shows no `xdg_toplevel.move` after any touch, and one after every mouse drag. 2. **tao's move is mouse-only.** `startDragging()` ends in tao 0.35.3's `WindowRequest::DragWindow` (`src/platform_impl/linux/event_loop.rs:336`), which calls `begin_move_drag(1, x, y, 0)` on the seat's *pointer* device. Started during a touch, GTK would send the move with a mouse serial, and the compositor would refuse it. ## What a fix needs - In the page: start the move from pointer events with `pointerType === 'touch'` (`pointerdown`, then `pointermove` past the threshold) on the `data-window-drag` regions, alongside the mouse path. - In the shell: a command that starts the move for the touchscreen device, e.g. `gdk_window_begin_move_drag_for_device()` with the device and position of the touch in progress, so the request carries the live touch's serial. Exactly one request per touch. ## Careful with mutter Until mutter has a NULL check in `touch_can_grab_surface()` (#7), a second move or resize request carrying the serial of a touch that mutter has already cancelled crashes GNOME Shell, and starting a move is what makes mutter cancel the touch. So the shell side must send the request once per touch and never repeat it, and it is best tested on a patched mutter first. ## Also seen With the touch-resize handlers blocked (#8), every finger lift still makes tao's `button-press` handler (`event_loop.rs:521`) answer GTK's emulated click with `xdg_toplevel.resize(seat, 0 or a stale mouse serial, 1)`, a top-edge resize. The compositor refuses it and it carries no touch serial, so it is harmless, but it is noise worth reporting to tao along with its touch resizing.

asxpi referenced this issue from a pull request that will close it,

2026-10-13 03:50:13 +00:00

Touch at the window border: no GNOME Shell crash, resize and move by touch #8