-performDragOperation:view: is not getting called for the drop.

That generally happens because the receiving view isn't set up correctly to retrieve the drop. registerForDraggedTypes: is finicky, especially with regards to old-style pboard names, and new-style URIs.

No... RenderViewImpl::OnDragTargetDragOver is returning 0 rather than 1. Therefore, -draggingUpdated: returns 0 (NSDragOperationNone) and AppKit never bothers to do the drop.

What's weird is that -[WebDragDestMac populateDropData:fromPasteboard:] fills in the DropData identically. I have no idea why Blink is unhappy here.

For the titlebar case, in WebViewImpl::dragTargetDragEnterOrOver the lines:

    if (!(dropEffect & dragData.draggingSourceOperationMask()))
        dropEffect = DragOperationNone;

are what clears out the drag. Searching for why the mask differs here.

Here are the two situations:

Dragging a file, the -[NSDraggingInfo draggingSourceOperationMask] is NSDragOperationEvery. For some reason, dragging a file into Chromium is NSDragOperationMove, so that's allowed.

For dragging a window proxy, the -[NSDraggingInfo draggingSourceOperationMask] is NSDragOperationCopy | NSDragOperationLink | NSDragOperationGeneric. Thus NSDragOperationMove isn't allowed and it fails.

So this is Chromium's problem. Why is NSDragOperationMove used? When you drag a file into Chromium, it is a copy, not a move.

DragController::dragEnteredOrUpdated calls
DragController::tryDocumentDrag calls
DragController::tryDHTMLDrag which has:

    if (dataTransfer->dropEffectIsUninitialized()) {
        operation = defaultOperationForDrag(srcOpMask);
    }

Since the drop effect is uninitialized (it's external) we fall to defaultOperationForDrag, which turns DragOperationGeneric into DragOperationMove.

Can we initialize external file drags to be copy?

I'm not sure. It doesn't seem possible to set the destination operation from the Chromium side. Should we bandaid from the Chromium side to say that if Blink says this is a move, then lie to AppKit and say it's a copy?

Reassigning to avi@ because he's actually be looking into this.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/57b70dae30c2bc7d60e70efd8ebae83e01fe9119

commit 57b70dae30c2bc7d60e70efd8ebae83e01fe9119
Author: avi <avi@chromium.org>
Date: Wed Jul 13 01:45:34 2016

Don't pick a drop operation that the source doesn't support.

If a page doesn't specify a drop operation, DragController's defaultOperationForDrag() makes an attempt to choose a reasonable operation based on what the source supports.

Unfortunately, if the source supports "generic" but not move, defaultOperationForDrag() chooses an operation that the source doesn't support, and the drop fails.

Fix it by not returning "move" if it is not supported.

BUG= 610085 
TEST=none
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel,mac_blink_rel,win_blink_rel

Review-Url: https://codereview.chromium.org/2030683003
Cr-Commit-Position: refs/heads/master@{#404885}

[modify] https://crrev.com/57b70dae30c2bc7d60e70efd8ebae83e01fe9119/third_party/WebKit/Source/core/page/DragController.cpp

 Issue 234931  has been merged into this issue.