XWayland: Drag-and-drop pastes clipboard content instead of the dragged file

[Reluckycf]

As mentioned in #11179
There is still an issue when you drag and drop to X11 programs running in XWayland. If there is anything else in the clipboard, the DnD will paste what's inside it instead of the file dragged.
I'm making this discussion since it has been almost a year and this issue hasn't been solved or answered.

On Hyprland 0.55.2 and this issue is still present.

dnd.mp4

Drag and Drop Pastes what's inside the clipboard.

Currently there is only one workaround:
clearing the clipboard with wl-copy --clear before drag and dropping.

But this doesn't solve the issue completely.

I tested what BastianBlokland did and removed this code on src/protocols/core/DataDevice.cpp:

#ifndef NO_XWAYLAND
    else if (const auto X11 = dev->getX11(); X11)
        offer = g_pXWayland->m_wm->createX11DataOffer(g_pSeatManager->m_state.keyboardFocus.lock(), sel);
#endif

38be63b

dnd_fix.mp4

Drag and Drop Fixed By removing createX11DataOffer

This worked completely. I can drag and drop correctly and haven't had any other issues related to the clipboard or DnD.

I'm planning on making a PR, but I'm not familiar with this code, so I need feedback. What does this actually do? Is it safe to remove it?
Further testing must be done.

Hope this issue is solved soon. This has driven me nuts for quite a while and having it fixed would be amazing.

[kidfromjupiter]

I have a similar issue with Qt application but in this case, its between both native wayland applications.

[kidfromjupiter]

I revisited this recently and I was mistaken. It's not between native Wayland applications, my qt application was running in xwayland without me noticing.

So issue is related to xwayland and matches the description seen elsewhere

[CyanEngineer]

Still an issue in hyprland 0.55.4
I would love to see a fix for this
@vaxerski I hope a ping is alright, now that we're at 5 upvotes :)

[pastawithpesto]

Additional controlled reproduction on the current v0.56.2 release. My visible symptom is that the file drop is not accepted, rather than clipboard text being pasted, but the backend isolation points to the same Wayland-to-XWayland DnD path described here.

Environment: Arch Linux / Omarchy, Hyprland 0.56.2-1, xorg-xwayland 24.1.13-1, Nautilus 50.2.2-1, and wechat-bin 4.1.1.8-1 (statically linked Qt 5.15.14/XCB).

Source	Target	Result
Nautilus (Wayland)	Chromium / WhatsApp Web (Wayland)	Works
Nautilus (Wayland)	WeChat / Qt 5 XCB (XWayland)	Fails
Nautilus (Wayland)	Termius (XWayland)	Fails (corroborating only)
Nautilus (XWayland)	WeChat / Qt 5 XCB (XWayland)	Works

The decisive comparison uses the same local file, WeChat window, and drop location. Changing only Nautilus from Wayland to XWayland changes the result from failure to success. This confirms that WeChat's X11/XCB drop handler works and isolates the failure to the cross-backend path.

WeChat cannot run natively on Wayland in this package: it ships a statically linked Qt 5.15.14 runtime without a Qt Wayland platform plugin. A freshly launched process with QT_QPA_PLATFORM=wayland still produces an XWayland window according to hyprctl clients -j.

This is also closely consistent with the Nautilus/Dolphin-to-QQ/WeChat report in #9472, although that issue was closed after #9405.

Report prepared collaboratively by @pastawithpesto with diagnostic assistance from AI agents (OpenCode + OpenAI Codex CLI).

[wabarTM]

go away ai

[pastawithpesto]

go away ai

you’re one of those, i’m just trying to solve my problem, which i did, with the route being pasted into wechat and not accepted by termius, good luck

[etherb0x]

Yeah, I've experienced this too, notably on Reaper, whose native Linux build only runs in XWayland atm (someone's working on a Wayland SDL port but it's unofficial and may take a long time to get integrated, if ever).

Drag / dropping from outside Reaper onto a timeline would briefly show a region where the file was intended to land, but then the drag/drop request would immediately abort without you releasing and the preview region on the timeline would disappear.

I pointed the clank at this for a bit as it was a workflow blocker, and the issue's temp resolved with some custom hyprland plugins, but I'd love to have this handling fixed upstream so I can drop reliance on a patch I don't understand/can't maintain.

I doubt you need more info as this has been discussed a bunch, but if you do want any kind of logs or more info on the shape of the problem, I can clank them up.