Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 29 users
Status: Verified
Owner:
User never visited
Closed: Apr 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Windows
Pri: 2
Type: Compat
M-5

Blocking:
issue 37997
issue 4890
issue 13362
issue 38591

Restricted
  • 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 arv@chromium.org, Jun 19 2009 Back to list
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.
 
dnd.html
2.0 KB View Download
Comment 1 by tony@chromium.org, 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 
WebCore/dom/Clipboard.cpp.
Comment 2 by arv@chromium.org, Jun 19 2009
test_shell on windows fails due to unimplemented functions.

UNIMPLEMENTED:
(..\third_party\WebKit\WebCore\platform\chromium\DragImageChromium.cpp:63 
WebCore::createDragImageFromImage)
UNIMPLEMENTED:
(..\third_party\WebKit\WebCore\platform\chromium\DragImageChromium.cpp:69 
WebCore::createDragImageIconForCachedImage)
UNIMPLEMENTED:
(..\third_party\WebKit\WebCore\platform\chromium\DragImageChromium.cpp:46 WebCore::deleteDragImage)
Comment 3 by arv@chromium.org, 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 arv@chromium.org, 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/webview_impl.cc (revision 17821)
+++ webkit/glue/webview_impl.cc (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 | 
DragOperationGeneric);

 // 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 tab_contents_view_win.cc.

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 arv@chromium.org, 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:

https://bugs.webkit.org/show_bug.cgi?id=26700
Comment 6 by jon@chromium.org, 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 
Available.
Comment 7 by arv@chromium.org, 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 arv@chromium.org, 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.
Status:
arv, will you have a chance to work on this soon?
Comment 12 by arv@chromium.org, 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 arv@chromium.org, 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 snej@chromium.org, 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 snej@chromium.org, 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 
operations.
Comment 24 by snej@chromium.org, 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 snej@chromium.org, 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 snej@chromium.org, 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 snej@chromium.org, Sep 8 2009
Oops, make that r25629. (25636 goes along with it, to unbreak the linux-views build.)
Comment 29 by snej@chromium.org, Sep 8 2009
Labels: -OS-Windows OS-All
Status: Fixed
Comment 30 by arv@chromium.org, 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 evan@chromium.org, 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 snej@google.com, 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 karen@chromium.org, 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 arv@chromium.org, 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 
owner. 
Comment 36 by arv@chromium.org, Mar 17 2010
Comment 37 by darin@chromium.org, Mar 17 2010
Comment 38 by tony@chromium.org, Mar 18 2010
Status: Started
Fixing for gtk first, will follow up with windows.
Labels: HTML5
Comment 40 by arv@chromium.org, Mar 22 2010
 Issue 35978  has been merged into this issue.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=42301 

------------------------------------------------------------------------
r42301 | tc@google.com | 2010-03-22 19:28:48 -0700 (Mon, 22 Mar 2010) | 8 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/web_drop_target_win.cc?r1=42301&r2=42300
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tab_contents/web_drop_target_win.h?r1=42301&r2=42300
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tab_contents/tab_contents_drag_win.cc?r1=42301&r2=42300
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tab_contents/tab_contents_view_win.cc?r1=42301&r2=42300

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: http://codereview.chromium.org/1132003
------------------------------------------------------------------------

Comment 43 by tony@chromium.org, Mar 24 2010
https://bugs.webkit.org/show_bug.cgi?id=36484 needs to be reviewed for this to work 
on win and linux.
Comment 44 by evan@chromium.org, Apr 2 2010
All the patches have landed.  Fixed?
Comment 45 by tony@chromium.org, Apr 5 2010
Status: Fixed
Yes, I think this is fixed.  arv, can you verify on Windows/Linux?
Comment 46 by arv@chromium.org, Apr 5 2010
Works on Windows and Linux.

Thanks.
Comment 47 by tony@chromium.org, Apr 6 2010
Status: Verified
Labels: -Area-Compat-Web bulkmove Area-Compat
Project Member Comment 50 by bugdroid1@chromium.org, 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 bugdroid1@chromium.org, 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 bugdroid1@chromium.org, Mar 13 2013
Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member Comment 53 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content Cr-Blink
Sign in to add a comment