Drag and drop uses clipboard instead

[m1neral-rocks]

Drag and drop in general is very inconsistent but lately I noticed if I ever copied anything to my clipboard, dragging and dropping anything to gimp/mpv(forced x11, if mpv runs in wayland drag and drop doesn't work)/davinci resolve will instead "drag and drop" whatever is in the clipboard. It behaves completely normally after a reboot if I don't copy anything to my clipboard. Sorry if there's a similar thread to this, I checked but couldn't find anything.

[BastianBlokland]

I have the same issue when dropping on xwayland windows. It seems to come from calling CXWM::createX11DataOffer() in CWLDataDeviceProtocol::sendSelectionToDevice().

CXWM::createX11DataOffer() seems to be just for drag and drops, at least it always add it to m_dndDataOffers collection, so I think it shouldn't be called from the copy path.

Locally it seems to work fine (including copy/paste) if I remove the call to CXWM::createX11DataOffer() from CWLDataDeviceProtocol::sendSelectionToDevice() but I'm not familiar enough with the code-base to know what problems that will cause.

[DoubyCz]

Same issue here. Dragging 5 MIDI files from Nautilus (native Wayland) to VLC playlist (XWayland) drops clipboard content instead (a folder I had previously copied). After clearing clipboard with wl-copy --clear, drag and drop works correctly.

Component	Version
Hyprland	0.53.3
VLC	3.0.21 (XWayland)
Nautilus	native Wayland

[kidfromjupiter]

This issue is present weirdly enough on Wayland to Wayland as well. I was building a QT app running on wayland and dragging from thunar (on wayland native ) to QT ( also running on wayland ) showed similar behavior

[CyanEngineer]

Related issue #14838
@vaxerski

[mjdegue]

Still reproducible on 0.56.2 — with a controlled measurement isolating it to the XWayland path

Confirming this is still present in Hyprland 0.56.2, and adding a measurement that pins it down.

System

Hyprland 0.56.2 (commit efb50993780079460b0cbed1363e2166a2de1d9f, tag v0.56.2)
xorg-xwayland 24.1.13
Arch Linux (Omarchy 4.0.1), kernel 7.1.9-arch1-2
NVIDIA RTX 4080 SUPER, nvidia-open-dkms 610.57.04
Drag source: Nautilus (native Wayland)

Method. I ran two instances of the same GTK3 drop probe simultaneously, differing only in
GDK_BACKEND — one XWayland (hyprctl clients reports xwayland: true), one native Wayland. Both
register the identical drop targets and just log what arrives. The same file was then dragged from
Nautilus onto each, seconds apart, with a 55-byte plain-text string on the clipboard.

Result — XWayland instance:

selection target : text/uri-list
raw length       : 55
raw repr         : b"<the exact 55 bytes of clipboard text>"
get_uris()       : ["<the exact 55 bytes of clipboard text>"]
                   exists=False        <-- not a path at all

Result — native Wayland instance, same drag:

selection target : text/uri-list
raw length       : 107
raw repr         : b'file:///home/<user>/.../Butcher_AI.3mf\r\n'
get_uris()       : ['file:///home/<user>/.../Butcher_AI.3mf']
                   exists=True

The bytes delivered to the XWayland client were byte-for-byte the CLIPBOARD contents, confirmed
with wl-paste. Same drag, same source, same moment — only the backend differs.

Workaround confirmed. wl-copy --clear (plus --primary) makes the XWayland drop deliver the
correct file:// URI. Re-populating the clipboard reintroduces the bug. This matches the repro in
the original report: copy any text, then drag a file.

Possible mechanism (not verified — offered as a lead). In SXSelection::sendData
(src/xwayland/XWM.cpp) the dispatch to clipboard / primary / DnD source looks correct, but the
block immediately below it guesses when the requested MIME isn't offered by the source:

if (std::ranges::find(MIMES, mime) == MIMES.end()) {
    // try to guess mime ...
    auto needle = mime;
    if (mime.contains('/')) needle = mime.substr(0, mime.find('/'));

text/uri-list reduces to needle text, which will match a text/plain clipboard offer. That is a
plausible route for text being returned where a URI list was requested. I have not confirmed
this is the branch that fires — I couldn't rule out the DnD source being resolved to the clipboard
source earlier on. Sharing it so someone who knows the XWM better can check quickly.

Real-world impact. Any XWayland client that treats the dropped payload as file paths gets
garbage. Bambu Studio segfaults outright on every drop while the clipboard is non-empty —
bambulab/BambuStudio#12052. The upstream thread also names GIMP,
mpv forced to X11, and DaVinci Resolve.

The probe script is short and self-contained; happy to attach it if useful for regression testing.

[wabarTM]

go away ai

[gentooza]

Hi folks
same issue here (and for a while! I thought it was an issue with new VLC 4.0 version just I've found this hyprland issue)
hyprland 0.56.2
gentoo GNU/Linux x86_64

when drag and drop songs to VLC it takes the one (or the file) stored in clipboard, not which I'm dragging :-/
As workaround I've to copy song first, and afterwards drag it down to VLC
XD terrible!

cheers and thanks to share