Text drag and drop in SDL 3 under Ubuntu 24.04 LTS in VirtualBox not working

[Dragon-Baroque]

SDL 3 at main commit 113eb6f of March 3rd 2025, Ubuntu 24.04.2 LTS updated, as VirtualBox guest.

Source Text : some text content of any page in Firefox,
Target 1 : SDL_VIDEO_DRIVER=x11 testdropfile
Symptom : The cross follows correctly the pointer, but the actual drop does not produce the text at all or produces it at the wrong place.
The few last lines of logging by testdropfile read :

Drop position on window 2 at (261.000000, 191.000000) data = (null)
Drop complete on window 2 at (261.000000, 191.000000)
Drop beginning on window 2 at (0.000000, 0.000000) data = (null)
Text dropped on window 2: We love keeping you safe at (0.000000, 0.000000)
Drop complete on window 2 at (0.000000, 0.000000) 

where the Text dropped on window lines may or may not occur,
but always a spurious Drop complete shows up followed by a Drop beginning at the wrong place,
making the Text dropped on window, when they occur, at the wrong place too.

Source Text : some text content of any page in Firefox,
Target 2 : SDL_VIDEO_DRIVER=wayland SDL_LOGGING=input=trace testdropfile
Symptom : The cross follows correctly the pointer, but the actual drop does not produce the text at all.
The few last lines of logging by SDL 3 and testdropfile read :

Drop position on window 4 at (208.238281, 167.238281) data = (null)
. In wl_data_device_listener . data_device_handle_drop on data_offer 0xff000002 in window 4 serial 908
. In Wayland_data_offer_receive for 'text/plain;charset=utf-8', buffer (0) at (nil)
. In wl_data_device_listener . data_device_handle_leave on data_offer 0xffffffff for serial -1
Drop complete on window 4 at (208.238281, 167.238281)

where the Wayland data_offer_receive fails to return the data.
This occurs when the data is instead in the Wayland Primary Selection, see the comment in src/video/wayland/SDL_waylandevents.c around line 2444.
I had that very same symptom by mid last year in native Fedora Linux, but the problem does not show anymore.
I do not recall whether and how I configured the Drag and Drop to prevent the data to fall into the Primary Selection, or whether it was silently fixed by some change in Wayland in between.

[Dragon-Baroque]

Following an advice from @Kontrabant, I retried with gedit instead of firefox.

But the problems persist unchanged - with SDL_VIDEO_DRIVER=x11 or SDL_VIDEO_DRIVER=wayland

[Kontrabant]

That's odd, when dragging the selected text 'Testing' from gedit into testdropfile on Fedora 41, I get:

Text dropped on window 6: Testing at (468.828125, 209.230469)
Drop complete on window 6 at (468.828125, 209.230469)

[Dragon-Baroque]

It works on Fedora 41 indeed. Unless, strangely, a VirtualBox Ubuntu is open in the desktop and then it does not work anymore.

Did you try with both SDL_VIDEO_DRIVER=x11 and SDL_VIDEO_DRIVER=wayland ?

But this is Ubuntu 24.04, and this is a VirtualBox guest. Sorry I cannot get my hands on a native Ubuntu.

[Kontrabant]

I think that I found the root issue, which is related to not flushing the queue when requesting the offered clipboard data. I should have tentative fix ready tomorrow.

[Kontrabant]

Sorry, didn't mean to close this as it happened automatically when merging the referenced pull.

I pushed some clipboard fixes to the main branch, can you test and see if this fixed your issue?

[Dragon-Baroque]

Sorry, little change.

• testdropfile over X11 is still showing the spurious Drop complete and Drop beginning events that cause the Drop to occur at the wrong place,
• testdropfile over Wayland is now having rare random drop successes with Wayland_data_offer_receive providing the actual data, but most often drop failures with Wayland_data_offer_receive providing 0 data like above. This may have changed from never successful to randomly rarely successful, it is hard to say firmly.

On the other hand I have mounted a Fedora 41 in VirtualBox, and it displays the same problems as Ubuntu 14.04.
Thus VirtualBox and/or the Host Windows Manager look like interfering with the Drag and Drop of the Guest VM.

I should actually retry with a native - non VM - Ubuntu, but this is a harder endeavor.

Meanwhile, I think I should close the issue, sorry for the disturbance.

[Semphriss]

Ubuntu 24.04 on bare metal here; testdropfile works as expected.

FWIW, I've had a multitude of issues with VirtualBox and drag-and-dropping, and rarely got it to work. It's possible the issue lies with VirtualBox.

[Kontrabant]

FWIW, I've had a multitude of issues with VirtualBox and drag-and-dropping, and rarely got it to work. It's possible the issue lies with VirtualBox.

I have 24.04 setup in Boxes, which is QEMU under the hood, and am still seeing random text-drop failures. The changes that I made yesterday to round trip when receiving data seemed to fix it at the time, but apparently the problem is sporadic, because it's back to randomly failing today.

I dug a little further and found the true cause: sometimes the compositor is sending a drag leave event instead of a drop event when the text is dropped, so SDL isn't causing the problem here. On top of that, while repeatedly dragging text trying to trigger the bug, I've had the compositor sporadically close the connection to the Wayland server after a drop operation a couple of times, killing the app in the process, so it definitely seems like drag & drop on 24.04 (maybe certain versions of GNOME?) has bugs when running in a VM for some reason.

[Dragon-Baroque]

After some cleanup, I have only one remaining case of gedit failing to Drag and Drop text into testdropfile.
It does not depend on VirtualBox, nor on Ubuntu.

In Fedora 41 Gnome over Wayland, and likewise in Ubuntu over Wayland, the SDL 3 X11 receiver SDL_VIDEO_DRIVER=x11 testdropfile receives the gedit emitted text at the wrong place 0, 0 instead of the mouse position.
The console shows a spurious sequence Drop complete + Drop beginning, where the drop location is reset.

Drop position on window 2 at (261.000000, 191.000000) data = (null)
Drop complete on window 2 at (261.000000, 191.000000)
Drop beginning on window 2 at (0.000000, 0.000000) data = (null)
Text dropped on window 2: We love keeping you safe at (0.000000, 0.000000)
Drop complete on window 2 at (0.000000, 0.000000) 

whereas all the following work OK :

Drop position on window 2 at (261.000000, 191.000000) data = (null)
Text dropped on window 2: We love keeping you safe at (261.000000, 191.000000)
Drop complete on window 2 at (261.000000, 191.000000) 

• in KDE over Wayland and Gnome over Wayland and Ubuntu over Wayland, with the SDL 3 Wayland receiver SDL_VIDEO_DRIVER=wayland testdropfile,
• in Gnome over X11 and Ubuntu over X11, with the SDL 3 X11 receiver SDL_VIDEO_DRIVER=x11 testdropfile,
• and interestingly, in KDE over Wayland, with the SDL 3 Wayland receiver SDL_VIDEO_DRIVER=wayland testdropfile,
  Could it be that the X11 provider in KDE over Wayland ( Xwayland ) works differently for the X11 provider in Gnome over Wayland ( xwaylandvideobridge ) ?

I am not sure whether the spurious sequence Drop complete + Drop beginning is what you mind with

sometimes the compositor is sending a drag leave event instead of a drop event when the text is dropped.

[Kontrabant]

What I am seeing on QEMU when dropping dragged text into the window fails is:

1. Drop begins
2. Drop moves
3. When the button is released over the window, the compositor sends an event saying the moving drop left the window instead of the expected event saying that the text was dropped. SDL sends a "drop complete" event in that case, as there is no "drop leave" event on the SDL side.

In your first example, I suspect the compositor sent a spurious drag leave+enter event combo for whatever reason. Ultimately, the root causes for the drop failures are incorrect events coming from the compositor, which are telling SDL to do the wrong thing.

KDE works perfectly for me in a VM as well, so I'm guessing that it's some kind of race condition in GNOME, which seems to become noticeable when running in a VM.