Touchpad two-finger scrolling over the button does nothing on Wayland

Summary: on a Wayland session, two-finger touchpad scrolling over the volume (brightness) widget does nothing, while the mouse wheel works; on X11 both work.

Environment:

  • Ubuntu 26.04.1 LTS; GTK 3.24.52
  • Wayland session, wlroots-based compositor (labwc 0.9.3); xfce4-panel 4.20.7 (Wayland-native, layer-shell)
  • xfce4-pulseaudio-plugin 0.5.1-1; xfce4-power-manager 4.20.0-1build1
  • Still present on master: xfce4-pulseaudio-plugin f1e39f29, xfce4-power-manager a18bb7be (checked 2026-10-12)

Steps to reproduce:

  1. Wayland session with the panel; the plugin's icon is visible.
  2. Put the pointer over the volume (battery) icon.
  3. Two-finger scroll on the touchpad; then compare with a mouse wheel.

Actual behaviour: touchpad does nothing; the wheel works. Expected behaviour: touchpad two-finger scrolling adjusts volume/brightness, as on X11.

Analysis: the widget requests only GDK_SCROLL_MASK and its handler covers only discrete directions. On X11 that is enough even for touchpads (scroll, including two-finger scrolling, is provided in the classic button 4/5/6/7 form and mapped by GDK to GDK_SCROLL_UP/DOWN). On Wayland there is no button fallback: finger scrolling carries no discrete steps (see trace above), so it exists only as GDK_SCROLL_SMOOTH, and GTK delivers smooth events only to widgets that added GDK_SMOOTH_SCROLL_MASK (GTK 3.4 rule). Hence the smooth stream is dropped before scroll_event() runs.

Suggested fix: add GDK_SMOOTH_SCROLL_MASK and handle GDK_SCROLL_SMOOTH by accumulating deltas into wheel-like steps; ignore smooth events whose source device is not a touchpad (the smooth companion of a wheel notch would otherwise double-step). A working patch is available (see the merge request).

AI/LLM disclosure (required by the Xfce AI/LLM Assisted Contribution Policy): the analysis, the patch and this report were prepared with the assistance of an AI/LLM.

PS: MR is ready if needed.

And plus I could not open gitlab.xfce.org in a Chromium-based browser while Firefox working fine. It turned out the response body is dropped server-side for Chrome-like requests. Minimal reproduction from one machine, one network (BE, Proximus):

curl -s -o /dev/null -w "%{http_code} %{size_download}B\n" \
    https://gitlab.xfce.org/users/sign_in
-> 200 14044B        (default curl User-Agent, full page)

curl ... -A "Chrome/138.0.0.0" https://gitlab.xfce.org/users/sign_in
-> 200 0B            (instant, reproduced several times)

-A "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Safari/537.36"
-> 200 14042B
-A "Googlebot/2.1 (+http://www.google.com/bot.html)"
-> 200 14044B
-A "" (empty)
-> 200 14044B