Add DnD from Chrome

Submitted by Andre Miranda @andreldm

Assigned to Andre Miranda @andreldm

Link to original bug (#16304)

Description

This is a follow-up of Bug 14919, which now supports DnD from Chrome: https://git.xfce.org/xfce/xfdesktop/commit?id=d47db7b

Theo Linkspfeifer said:

This is the actual commit: https://git.xfce.org/xfce/xfdesktop/commit/?id=5a8c7f6

Do you still plan to implement this? It would be nice to have it working in Thunar also.

Yes, but don't hold your breath, merge requests are always welcome

added 5. Drag-and-Drop label

added 2. Feature label

mentioned in merge request !269 (merged)

Better late than never, @lastonestanding can you please test !269 (merged)?

Nice! It works great.

I encountered a weird case though (affects both Thunar and xfdesktop). Go to the Xfce 4.16 tour site and try to drag'n'drop the image which shows the new icons. No file will be created at the target location.

GLib-GIO-CRITICAL **: g_output_stream_write_all: assertion 'buffer != NULL || count == 0' failed

Thanks for testing and nice catch, I never noticed this, unsurprisingly because I barely use Chrome(ium).

But something happens, there is a delay of 20~30 seconds for thunar_standard_view_drag_data_received to be called after dropping, an empty file named "Untitled Document" is created and that critical message printed.

The problem is related to the image size, any image a bit larger than 1 MiB triggers this bug.

I don't see anything suspicious on our side, if Thunar was doing something in those 20~30 seconds I guess it would freeze, which is not the case. This could be a bug in glib or chromium. I don't know if xfsettingsd (more precisely its clipboard manager) plays a role here.

There is as well g_output_stream_write_all_async ... I did not try if it changes something, just saw it while dong a review and thought it sounds like it could have an effect for it

g_output_stream_write_all does not block, it returns immediately, so I dont' see see how the async function would help here.

In fact, when thunar_standard_view_drag_data_received is called after the long delay, the GtkSelectionData passed to it is already "invalid", i.e. it misses the file name and the data itself.

The exact same problem is observed in Nemo and Nautilus, there is a small glitch when the image is dropped, i.e. the thumbnail stays close to the cursor for 1~2 seconds. Even in gnome shell session I could reproduce it. Definitively this is a problem upstream (glib) or with chromium.

The difference with those file managers is that both check if data is valid before reading. I pushed a check to !269 (merged) so we don't get critical messages anymore nor an Untitled Document.

closed with commit f03b13e9