New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 14654 link

Starred by 29 users

Issue metadata

Status: Verified
User never visited
Closed: Apr 2010
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Compat

issue 4890
issue 13362
issue 37997
issue 38591

  • Only users with EditIssue permission may comment.

Sign in to add a comment

HTML5 Drag and drop, effectAllowed and dragEffect broken in Chrome.

Project Member Reported by, Jun 19 2009

Issue description

The effectAllowed and dropEffect properties of the DataTransfer object allows 
the page to decide what kind of effect dragging things has. For example if I 
set effectAllowed to "linkMove" and then the dropEffect to "move" the effect 
is to do a move dnd action and we should show the move cursor.

In Chrome, if I set effectAllowed to something that does not contain "copy" I 
cannot do any drag and drop.

FWIW, this works in Safari 4.
2.0 KB View Download

Comment 1 by, Jun 19 2009

Status: Available
Does it work in test_shell on windows?

Not sure if I'll have time to look at this, but the setters for this appear to be in 

Comment 2 by, Jun 19 2009

test_shell on windows fails due to unimplemented functions.

(..\third_party\WebKit\WebCore\platform\chromium\DragImageChromium.cpp:46 WebCore::deleteDragImage)

Comment 3 by, Jun 19 2009

Safari for Windows has the exact same problem.

It seems like the effectAllowed is ignored and always treated as copyLink

Comment 4 by, Jun 19 2009

OK. I got "move" to work. The initial value for kDropTargetOperation does not contain DragOperationGeneric. DropOperationGeneric is used for move.

--- webkit/glue/ (revision 17821)
+++ webkit/glue/ (working copy)
@@ -137,7 +137,7 @@
 // The webcore drag operation type when something is trying to be dropped on
 // the webview.  These values are taken from Apple's windows port.
 static const WebCore::DragOperation kDropTargetOperation =
-    static_cast<WebCore::DragOperation>(DragOperationCopy | DragOperationLink);
+    static_cast<WebCore::DragOperation>(DragOperationCopy | DragOperationLink | 

 // AutocompletePopupMenuClient
 class AutocompletePopupMenuClient : public WebCore::PopupMenuClient {

The comment explains why Safari for Windows is having the exqact same problem.

However, we still never show the link, nor the move cursor. It turns out that we never return 
DROPEFFECT_LINK nor DROPEFFECT_MOVE. GetPreferredDropEffect always returns DROPEFFECT_COPY because 
we hard code to always use DROPEFFECT_COPY | DROPEFFECT_LINK in

I think I've reached my limit for now. I'm not sure how the drop effect is supposed to get 
propagated from the renderer to the browser thread.

Comment 5 by, Jun 25 2009

Labels: Mstone-3
I think I got a better understanding of this now. Setting allowedEffect has no effect 
in Chrome nor Safari 4 on Windows but works fine on Safari 4 on Mac.

I filed a WebKit bug for the Safari 4 Win case:

Comment 6 by, Jul 8 2009

Status: Assigned
Has owner, should have been assigned status.  If you are not the right owner 
then please remove your name from the owner field and change the status to 

Comment 7 by, Jul 9 2009

Status: Available
Not actively looking at this at the moment but it is still blocking the NNTP.
Labels: Mstone-4
Should not block Mstone:3

Comment 9 by, Jul 14 2009

This is blocking the NNTP which is blocking mstone-3
Labels: -Pri-2 -Mstone-4 Pri-1 Mstone-3 ReleaseBlock-Stable
Thanks! Sorry about that.
arv, will you have a chance to work on this soon?

Comment 12 by, Jul 15 2009

I don't think I have time to look at this in at least 2 weeks.
Status: Available
I'll look for an owner.
Jeremy, would you like to try your hand at this?
Status: Assigned
I'm short on cycles.  Jens is going to take a look.

Comment 17 by, Jul 28 2009

Labels: NNTP

Comment 19 by Deleted ...@, Aug 6 2009

Any progress on this?
Labels: -Mstone-3 -ReleaseBlock-Stable Mstone-4
I'm taking this off the stable block list for NNTP, please let me know if we need to
keep this on for WebKit.

Comment 22 by, Aug 17 2009

Labels: HTML5
I'm stymied on the other WebKit bug I was working on, so I'll go back to working on this one.

Comment 23 by, Aug 18 2009

Here's what I've worked out so far:
1. The OnDragOver IPC call needs to pass the current drag source operation mask. Currently 
WebViewImpl::DragTargetDragOver has no way of knowing what it is, so there's a hack that makes it use a 
hardcoded value  called kDropTargetOperation.
2. The dropEffect set by the target handler needs to be masked against the source operation mask, to disallow 

Comment 24 by, Aug 18 2009

3. The UpdateDragCursor message sent back to the browser only contains a boolean saying whether a drop is 
allowed. It instead needs to return a DragInfo with the allowed operations. This will allow the browser to set the 
right cursor, and also to send that operation mask back to the platform drag API.

Comment 25 by, Aug 18 2009

4. On the drag-source end, the effectAllowed (source drag operation mask) doesn't get passed from the 
renderer up to the browser in the StartDragging IPC message; so when the platform drag starts, it's just 
hardcoded to use Copy.
Some of the problems are in WebCore, so I've just sent out a patch for WebKit  bug 26700  to fix those.
After those are in, I can send out the (larger) Chromium patch for the rest of the stuff.

Comment 27 by, Sep 8 2009

The WebCore patch is languishing in review :(
I determined the Chromium fix wasn't actually dependent on it (although the drag behavior won't be 100% 
correct yet), so I got that reviewed and checked in as r25636.

Comment 28 by, Sep 8 2009

Oops, make that r25629. (25636 goes along with it, to unbreak the linux-views build.)

Comment 29 by, Sep 8 2009

Labels: -OS-Windows OS-All
Status: Fixed

Comment 30 by, Dec 22 2009

Labels: -OS-All -Mstone-4 -NNTP OS-Linux Mstone-5 Area-Compat-Web OS-Windows
Status: Assigned
This is still not working on Windows nor Linux. Setting effectAllowed works on Mac.

Comment 31 by, Jan 6 2010

Labels: -Pri-1 Pri-2
Status: Untriaged
I'm guessing that Jens isn't working on this; feel free to correct me if I'm wrong.

Comment 32 by, Jan 7 2010

The effectAllowed needs to be communicated to/from the native platform drag-and-
drop APIs on Windows and Linux. I have no familiarity with those APIs, so I just did the 
Mac version. I think I filed corresponding bugs to cover doing those, but I'm not certain; 
it's possible I forgot to. (The end of this work was a nightmare of dealing with the 
commit approval on the WebKit side, and I may have been too frazzled...)

Comment 33 by, Jan 11 2010

Labels: -HTML5 WebKit-WebApps karenianreview
Labels: -karenianreview
Status: Assigned
Erik - is this something you have time to look at for win/linux now?

Comment 35 by, Jan 14 2010

Ian: Sorry, I don't have any time to work on this 
at the moment. 

It would probably be better to find another 

Comment 36 by, Mar 17 2010

Comment 37 by, Mar 17 2010

Comment 38 by, Mar 18 2010

Status: Started
Fixing for gtk first, will follow up with windows.
Labels: HTML5

Comment 40 by, Mar 22 2010

 Issue 35978  has been merged into this issue.
The following revision refers to this bug: 

r42301 | | 2010-03-22 19:28:48 -0700 (Mon, 22 Mar 2010) | 8 lines
Changed paths:

Hook up HTML5 effectAllowed and dragEffect on Windows.

This is the chrome side plumbing, but some patches need to
land on the WebKit side.

BUG= 14654 

Review URL:

Comment 43 by, Mar 24 2010 needs to be reviewed for this to work 
on win and linux.

Comment 44 by, Apr 2 2010

All the patches have landed.  Fixed?

Comment 45 by, Apr 5 2010

Status: Fixed
Yes, I think this is fixed.  arv, can you verify on Windows/Linux?

Comment 46 by, Apr 5 2010

Works on Windows and Linux.


Comment 47 by, Apr 6 2010

Status: Verified
Labels: -Area-Compat-Web bulkmove Area-Compat
Project Member

Comment 50 by, Oct 13 2012

Blocking: -chromium:13362 -chromium:37997 -chromium:4890 -chromium:38591 chromium:13362 chromium:4890 chromium:38591
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 51 by, Mar 10 2013

Labels: -Type-Bug -Area-WebKit -Mstone-5 -WebKit-WebApps -Area-Compat Cr-Content M-5 Cr-Content-WebApps Type-Compat
Project Member

Comment 52 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 53 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment