Touch drag and drop on Linux

#451651623 Filed 2025-10-13 TouchDragEndContextMenu sampler

Purpose

What this page checks

This sampler logs dragstart, dragend, drop, and contextmenu for draggable link and image targets. It is useful for a manual or CDP-based smoke check of the Linux touch drag path.

The page prevents the native context menu after logging it, so the expected signal is the logged contextmenu event.

Demo

Touch drag-and-drop in action

Screen recording of long-press → drag → drop on this page running a patched Chromium build (Linux touch DnD enabled) under a Wayland compositor.

Live sampler

touch support: checking pointer events: checking

Draggable link

drag this link

Long press, then move or release in place.

Draggable image

Matches the link/image path covered by Blink tests.

Drop zone

A successful drop should not be followed by a context menu.

Event log last event: none

Log is empty.

Expected results

With TouchDragAndDrop and TouchDragEndContextMenu enabled

Long press on link or image and move: dragstart should be logged.

Long press on link or image and release in place with no drop operation: contextmenu should be logged after drag end.

Long press and drop on the drop zone: drop should be logged, and no extra context menu should follow.

Run with Chrome DevTools Protocol

Launch Chrome

Start Chromium with remote debugging and the feature enabled:

out/Default/chrome \
  --user-data-dir=/tmp/chrome-touch-dnd-451651623 \
  --remote-debugging-port=9222 \
  --touch-events=enabled \
  --enable-features=TouchDragAndDrop \
  https://static.januschka.com/i-451651623/

CDP runner

Copy the Node script below into a local file, for example /tmp/touch-dnd-cdp.js, then run node /tmp/touch-dnd-cdp.js. It connects to Chrome on port 9222, opens this page if needed, and dispatches touch sequences to the link, image, and drop zone.

Configure touch display

Wayland (GNOME / Mutter)

Map the external touchscreen to the correct monitor (so coordinates aren't stretched across the whole layout). Find the touch device's vendor:product ID via the kernel (e.g. 27c0:0859 for a wch.cn screen) and the target output's EDID via DBus, then bind them with gsettings:

gsettings set "org.gnome.desktop.peripherals.touchscreen:/org/gnome/desktop/peripherals/touchscreens/<vendor>:<product>/" output "['<edid-vendor>', '<edid-product>', '<edid-serial>']"

X11 / Xorg

Use xinput list to find the slave touch device id, then map its coordinates onto the target output (e.g. DP-1):

xinput --map-to-output <touch-device-id> DP-1

If Chromium DCHECKs IsTouchDevice(deviceid) on the first touch event, also pass --touch-devices=<master-id>,<touch-id> on the command line so its TouchFactory registers the device.

Notes

Mouse vs touch emulation

Chrome Remote Desktop mouse input is not real OS touch input. DevTools device emulation can make page JavaScript see touch-like input, but it is not the strongest validation of Chromium's native gesture and drag controller path. The CDP runner and Blink tests are better signals.