simon-git: xcopy (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  a320e86 In drag-and-drop, handle 'target format unsupported' case.

Repository:     https://git.tartarus.org/simon/xcopy.git
On the web:     https://git.tartarus.org/?p=simon/xcopy.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2017-08-15 18:33:30

commit a320e867acafec852b0f61d2e3e277a1eef90bb6
web diff https://git.tartarus.org/?p=simon/xcopy.git;a=commitdiff;h=a320e867acafec852b0f61d2e3e277a1eef90bb6;hp=0b986051ac0cc22a47d86cfbada03e3662adf74f
Author: Simon Tatham <anakin at pobox.com>
Date:   Tue Aug 15 18:28:55 2017 +0100

    In drag-and-drop, handle 'target format unsupported' case.
    
    After the first call to convert_selection_outer, we were setting the
    drop_transfer_ready variable to False, meaning that we would refuse
    any further requests for the selection contents (in case a receiver
    requested the data twice by mistake). But we did this even if
    convert_selection_outer ended up returning None to indicate that the
    requested format isn't supported. So if a receiver first requests the
    selection in a format we don't support, and then falls back to the one
    we do, then we'll refuse the second request on the basis that it's had
    its chance already.
    
    This has come up recently because Firefox has started requesting
    drag-and-drop selections as type "application/x-moz-file", and only
    falling back to "text/uri-list" if the former fails. So if someone is
    trying to use xcopy to transfer a drag-and-drop filename in the latter
    format, then Firefox wouldn't successfully receive it, because the
    initial request in a different unsupported format would trip this bug.
    
    Fixed so that we now only move to the 'done' state after we actually
    successfully transfer some selection data.

 xcopy.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)