[PATCH wayland] protocol: Improve data source notification around DnD progress

[Michael Catanzaro]

One problem with this model is that a broken or malicious client could
force the drag source to be leaked by [sending accept and] never
destroying its data offer... but only once per user-initiated drag, so
we can probably ignore that issue....

On Thu, 2015-10-01 at 12:00 +0200, Carlos Garnacho wrote:
> This is in order to be able to emit .cancelled if there is no
> agreement between source and destination about the data to be
> transferred. Otherwise every drop on any client with a wl_data_device
> would seem successful.

Ah, so the goal is to allow the drag source to know if the drop
succeeded. The only solution I can think of that avoids the problem I
mention is to delay the canceled event until the data offer is
destroyed. Then there is no race, and the drag source must simply wait
until drag_finished or a later drag_cancelled if it wants to indicate
to the user if the drag succeeded or not (the drop success indication
would be delayed until the data transfer is completed). I don't see any
problems with such a scheme, but if you can find one, then I think we'd
have to go with your solution and just say that my problem is a client
bug.

> I know .accept has had no functional role in the DnD state machine
> till now (besides UI feedback on the source-side, setting the
> appropriate cursor/dnd surfaces mostly), it made sense to me to reuse
> this though because compositor-side UI feedback and overall DnD
> outcome would be in sync for virtually every usecase I can imagine. I
> would expect .accept() to be called regularly on DnD motion over a
> surface, the pointer moves across inner widgets that accept different
> mimetypes or none.

Chrome does call it regularly on DnD motion, but only beginning after
it has received all the data.

> Actually, IMO there should be checks somewhere about the mimetype
> being one of the offered ones, in order to behave properly on wrong
> requests, although that means keeping the mimetype list in memory
> instead of just forwarding it.

If you mean that the mime type sent in accept or receive requests
should always be one of the offered mime types, then having the
compositor check for that is a fine idea that can't possibly hurt
anything.

> However, I can imagine other usecases where we don't know any
> concrete
> mimetype beforehand, eg. a "paste as html/plain text" popup menu on
> .drop_performed, there'd be no other way in these cases than
> preemptively picking one, as you say in your other mail.

Deciding later which type of data to actually use doesn't require any
interaction with the source process if the data has already been
received (as is the case for Chrome), and if the data has not already
been received, the receive request must specify an offered mime type.
In fact, Chrome's DnD backend doesn't ever know anything about which
mime type will actually be used (and in accept messages, it just sends
back whatever the first offered mime type was, fdo#91950).

Now, verifying that receive requests use a previously-accepted mime
type would be problematic for Chrome, since we receive and then accept
instead of vice-versa, but I don't think that's what you're proposing?

>  So perhaps it
> makes sense to split into a request with a boolean after all?
> Nonetheless, for the case of GTK+, both would be called from the same
> place (and .accept is already invariably called with the first
> mimetype from the list, hmm...)

Can you clarify your idea? I am a bit lost now. :)

Michael