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

[Michael Catanzaro]

On Thu, 2015-10-01 at 21:36 +0200, Carlos Garnacho wrote:
> But this is a very valid concern, if you preemptively accept() with a
> random mimetype, the user quickly finishes the drag before transfers
> are done, and it isn't accepted in the end, you'd get the wrong
> feedback, and the wrong outcome in move operations, where the source
> may think it's ok to delete the data. The other option is not
> accept()ing until the first transfer is done like you do right now,
> and train the user to wait long enough on huge dnd transfers, so
> early
> drops turn out cancelled. There'd usually be at least cursor feedback
> from the drag source when accept() finally happens. Both options are
> somewhat disconcerting, I admit...

I was thinking we should go with the second option (i.e. the current
behavior of your patches), because I can't think of any way to avoid
the problems you bring up. But there is another problem: when Chrome
sends accepts, they are not necessarily intended for the current
coordinates of the pointer. There is a round-trip needed between the
GPU process (which uses Wayland) and the browser process (which makes
decisions about where stuff is allowed to be dropped). So by the time
the GPU process receives from the browser process the instruction to
send the accept, another motion event(s) could have occurred, and the
accept would be stale. It's easy to detect that occurrence, but not
avoid it, because the only thing to do would be to drop stale accepts,
and that could result in there being no drag feedback at all until the
pointer stops.

Currently, that's no problem because a new accept will be coming soon,
and the accepts don't affect correctness. But now this too could cause
a drop to fail on the destination side, when the source side thinks the
drop has succeeded!

> I meant, adding a separate .set_droppable() request with a boolean
> parameter that indicates success, so .accept()'s role remains
> unchanged. There's the downside that you decouple source-side
> feedback
> from the rest of the DnD operation outcome (compositor-side feedback
> and events emitted). Again, this is something that happens on XDND,
> eg. by acknowledging one status on XdndStatus and finishing with
> another one on XdndFinished, feels like late 90's again :).

What would be the point of a separate .set_droppable() request? I don't
see what problem that would solve.

Thanks,

Michael