We should for both backends actually. Fun fact, gtk+/tests/testdnd rootwindow drop feature fails, and it's apparently because the other peer of application/x-rootwindow-drop has stayed in libnautilus-private till these days...

so, it appears we aren't actually using application/x-rootwindow-drop for this, but we need wayland protocol to transmit drop status back to the source. Right, Carlos ?

Created attachment 323528 [details] [review]
wayland: Always send focus() when starting a pointer grab

Even if the focus is NULL, we may want the current grab focus code
to be run.

Created attachment 323529 [details] [review]
wayland: Force an initial focus in meta_wayland_drag_grab_set_focus()

We want some initial processing, even if the current focus didn't change.
This could be for example the case of starting DnD too close to the window
edge and out of it. At the point start_drag() is called, the current
pointer focus is already NULL, so set_focus() would simply bail out here.

Created attachment 323530 [details] [review]
wayland: Implement support for the x-rootwindow-drop target

This target is set whenever DnD moves towards an area between surfaces.
Although no offer is set and data is actually not read, drag sources
offering this mimetype will be able to behave just like they used to
do in X11.

Review of attachment 323529 [details] [review]:

Is the processing you need done, calling

meta_wayland_data_source_set_current_offer (drag_grab->drag_data_source, NULL);

? Why isn't that done unconditionally at the start before the early return then?

Review of attachment 323530 [details] [review]:

I still have a question below but this looks good anyway

::: src/wayland/meta-wayland-data-device.c
@@ +782,3 @@
+    meta_wayland_drag_source_fake_acceptance (source, ROOTWINDOW_DROP_MIME);
+  else if (source)
+    meta_wayland_data_source_target (source, NULL);

Ok, you're doing more things here. But still, why can't this be done before the early return at the beginning ?

(In reply to Rui Matos from comment #6)
> Review of attachment 323529 [details] [review] [review]:
> 
> Is the processing you need done, calling
> 
> meta_wayland_data_source_set_current_offer (drag_grab->drag_data_source,
> NULL);
> 
> ? Why isn't that done unconditionally at the start before the early return
> then?

The MetaWaylandPointerGrabInterface focus method gets called once per motion event (the callstack is meta_wayland_pointer_update->repick_for_event->sync_focus_surface->grab.focus->meta_wayland_drag_grab_set_focus), and that early return is there to catch cases where focus didn't actually change. 

Doing things early there would mean we'd be replying rather often with the selected mimetype/action. I don't think that's the end of the world, but IMHO it's better not to do calls we know redundant. 

Also, in actual focus switch, I think it's better to make event emission in the same exact order as if the pointer moved towards a surface. Say the pointer is leaving from the drag-source surface to the "root window", it'd receive new data_source.target/action events before its data device receives .leave, while the drag dest (still equal to the drag-source in this case) supposedly owns/manages a wl_data_offer. I guess this would not bring ill effects if the drag dest is receiving data_device.leave and must destroy the wl_data_offer asap, but...

Review of attachment 323529 [details] [review]:

Ok, makes sense

Review of attachment 323528 [details] [review]:

++

Thanks for the review! pushed all three

Attachment 323528 [details] pushed as 82153ff - wayland: Always send focus() when starting a pointer grab
Attachment 323529 [details] pushed as 51e4491 - wayland: Force an initial focus in meta_wayland_drag_grab_set_focus()
Attachment 323530 [details] pushed as 3d67bfd - wayland: Implement support for the x-rootwindow-drop target