GitLab

TL;DR:

Wayland Protocol needs to be extended to make it possible to properly
support full Chromium's tab dragging experience. Further details in the
Design document [1]. This is the first of a patch series which
implements extended-drag extension in Exo compositor, adding the
protocol descriptor XML file, boilerplate code as well as a stub
implementation of it. Follow-up CLs will incrementally implement the
extension features and start using it in Chromium Ozone/Wayland
(client-side).

-----------------------------------------------------------------------
An overview of how this protocol is aimed to be used in a tabdrag-like
scenario, but in generic terms, is outlined below:

1. An UI item (eg: a tab in a tab bar) starts to be dragged within shell
surface A owned by source client S. At some point, it gets far enough
from its original location and S then starts a Wayland "extended drag"
session, which protocol-wise requires to:

1.1. Create a wl_data_source, set one (or more) mime type and the
supported dnd actions;

1.2. Create a zcr_extended_drag_source for the newly created drag
source. Here it is possible to set a few options, such as:
  - ALLOW_SWALLOW: determines that the dragged item can be attached (or
  incorporated, also referred to as "swallow" in this protocol) to
  another surface, including use cases such as Chrome's tab drag.
  - ALLOW_DROP_NO_TARGET: In the standard DND protocol, dropping
  something outside shell surfaces lead to a wl_data_source::cancel,
  which is problematic in use cases such as tab drag, preventing us from
  detecting when it was really cancelled, e.g: ESC pressed.
  - LOCK_CURSOR: Keep the cursor shape unchanged during the whole
  session. Ultimately, having an extended drag source attached to the
  wl_data_source used to wl_data_device::start_drag instructs the
  compositor to run the drag session in the "extended mode".

1.3 Start the drag session as usual (i.e: wl_data_source::start_drag),
with a null drag icon surface. Assuming that we're still in attached
mode for now. In addition, from now on, client S must start watching for
wl_data_device::{enter,leave,motion} events in order to be able to
detect the next actions and state transitions as the user drags the UI
item around.

1.4 Store the (x_offset, y_offset) location where the drag started in S
and keep them synced to the values received in wl_data_device::motion()
events.

2. Once the drag gets far enough from the original UI item's container
(ie: tab bar), it's time to detach (or unswallow) it from surface A. To
achieve it, client S must:

2.1. Create a new wl_surface B + its corresponding shell surface, e.g: a
toplevel xdg surface where a new detached browser window will rendered
to in Chrome's tab drag use case;

2.2. Issue a zcr_extended_drag_source::drag(B, x_offset, y_offset)
request, which tells the compositor (in advance) that B must be set as
the extended-drag surface, using x and y offsets to translate it from
the current pointer location;

2.3. Map surface B (configure, attach buffer, etc) as usual. After this
B's shell surface should show up tied to the mouse pointer and the
compositor is supposed to take care of it, putting it in a special state
where, for example, it does not receive events, etc, acting just like a
standard DND "drag icon". At this point, the "unswallow" operation is
done and the extended-drag session enters in detached state.

3. Supposing the drop happens while in detached state, there are 2
possible flows, which depend on whether ALLOW_DROP_NO_TARGET config is
set or not (see 1.2). If it is set, wl_data_source::dnd_finished event
is sent to the source client S, otherwise wl_data_source::cancelled is
sent.

4. Otherwise, if before dropping, the pointer enters surface C, owned by
client T. T receives a wl_data_offer O through wl_data_device::offer
event as usual, to which it can attach a zcr_extended_drag_offer XO to
it by issuing zcr_extended_drag::get_extended_drag_offer(O). Target
client T, then starts monitoring wl_data_device::motion events, so that
it can trigger a swallow based on where the pointer is. If B is dragged
over a region that leads to a swallow, T must:

4.1 Issue a zcr_extended_drag_offer::swallow(serial, mime) request,
asking source client S to incorporate the dragged item into its UI.
S then receives a zcr_extended_drag_source::swallow(mime) event and
it can accept it by calling zcr_extended_drag_source::drag(null, 0, 0),
so client T can finally render it as part of its UI. At this point, the
session is back to a state similar to 1.4. So, similarly to 2, once the
drag gets far enough, T might want to unswallow (aka: detach) the UI
item. In order to do so it must:

4.1.1 Call unswallow(serial, mime, x_offset, y_offset) on the
extended-drag offer XO (created at step 4), whereas the offsets tell how
the dragged surface must be positioned related to the pointer location.
Client S will then receive a zcr_extended_drag_source::unswallow(mime,
x_offset, y_offset) event so that it can create and map a new surface D
and issue a zcr_extended_drag_source::drag(D, x_offset, y_offset), same
as in step 2.3, making surface D to show up under the pointer. At target
side, T can then re-render its UI without the dragged item. This
finishes the unswallow (or detaching) operation, transitioning the
session back to "detached" state.

[1] https://docs.google.com/document/d/1s6OwTi_WC-pS21WLGQYI39yw2m42ZlVolUXBclljXB4/edit?usp=sharing

Bug: 1099418
Change-Id: I8d876e96e45717c625c1d1bdcc269b100524cbc7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2307653
Commit-Queue: Nick Yamane <nickdiego@igalia.com>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Cr-Commit-Position: refs/heads/master@{#811055}