Summary
Chromium-based browsers (Google Chrome, Brave) cannot start an internal drag-and-drop under Treeland's native Wayland backend. The most visible symptom: in the bookmarks bar / bookmarks manager the pointer will not "grab" a bookmark to move or reorder it. The drag never begins — press-and-move does nothing, and releasing just triggers a normal click.
Forcing the browser onto XWayland (--ozone-platform=x11) is a complete workaround, so this is specific to Chromium's native-Wayland (Ozone/Wayland) drag path as handled by Treeland.
Environment
- Treeland
0.8.15-3 (Arch Linux, DDE session, XDG_SESSION_DESKTOP=Treeland)
- qt6-base
6.11.1-1
- Google Chrome
150.0.7871.114, Brave 150.1.92.141
- Kernel
7.1.3-zen2-2-zen
Steps to reproduce
- Launch Google Chrome or Brave with no ozone override (auto-selects the Wayland backend on Treeland).
- Open the bookmarks bar (or
chrome://bookmarks).
- Press on a bookmark and try to drag it to a new position.
Expected: the bookmark is picked up and follows the cursor; dropping reorders it.
Actual: the pointer never grabs the item; no drag starts. Same for dragging a link onto the bookmarks bar and dragging to reorder tabs.
Scope / what it is not
- Not a global compositor break: native DTK/Deepin apps (file manager file drags, desktop icon drags) drag with zero issues on the same session. Only Chromium's own drag loop fails.
- Not client-specific: the identical Chrome/Brave builds drag correctly on GNOME (Mutter) and KDE Plasma (KWin) under Wayland. Treeland is the only compositor of the three where it fails, which points at Treeland's
wl_data_device / drag-grab handling rather than the browser.
Workaround
Run the browser on XWayland instead of native Wayland:
(e.g. add that line to ~/.config/chrome-flags.conf / ~/.config/brave-origin-flags.conf). With XWayland the bookmark drag grabs and works normally, which is what isolates the fault to the native-Wayland DnD path.
Notes
- Likely related area: Treeland's implementation of
wl_data_device.start_drag / the implicit pointer grab that Chromium relies on to begin a DnD. Compare against Mutter/KWin, which accept the same sequence.
- Happy to gather
WAYLAND_DEBUG=1 logs or a treeland protocol trace of the failed start_drag if that would help pinpoint it.
Summary
Chromium-based browsers (Google Chrome, Brave) cannot start an internal drag-and-drop under Treeland's native Wayland backend. The most visible symptom: in the bookmarks bar / bookmarks manager the pointer will not "grab" a bookmark to move or reorder it. The drag never begins — press-and-move does nothing, and releasing just triggers a normal click.
Forcing the browser onto XWayland (
--ozone-platform=x11) is a complete workaround, so this is specific to Chromium's native-Wayland (Ozone/Wayland) drag path as handled by Treeland.Environment
0.8.15-3(Arch Linux, DDE session,XDG_SESSION_DESKTOP=Treeland)6.11.1-1150.0.7871.114, Brave150.1.92.1417.1.3-zen2-2-zenSteps to reproduce
chrome://bookmarks).Expected: the bookmark is picked up and follows the cursor; dropping reorders it.
Actual: the pointer never grabs the item; no drag starts. Same for dragging a link onto the bookmarks bar and dragging to reorder tabs.
Scope / what it is not
wl_data_device/ drag-grab handling rather than the browser.Workaround
Run the browser on XWayland instead of native Wayland:
(e.g. add that line to
~/.config/chrome-flags.conf/~/.config/brave-origin-flags.conf). With XWayland the bookmark drag grabs and works normally, which is what isolates the fault to the native-Wayland DnD path.Notes
wl_data_device.start_drag/ the implicit pointer grab that Chromium relies on to begin a DnD. Compare against Mutter/KWin, which accept the same sequence.WAYLAND_DEBUG=1logs or atreelandprotocol trace of the failedstart_dragif that would help pinpoint it.