Fix HTML5 effectAllowed and dragEffect on Chrome Linux.

Fix HTML5 effectAllowed and dragEffect on Chrome Linux.

This hooks up all the chrome side plumbing, but there are a couple
webkit changes that need to happen for this to fully work.

BUG=14654
Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=42306

[Evan Stade, 2010-03-18 15:35:36]

http://codereview.chromium.org/1084003/diff/2001/3002
File app/gtk_dnd_util.h (right):

http://codereview.chromium.org/1084003/diff/2001/3002#newcode81
app/gtk_dnd_util.h:81: // Convenience method for converting between a web drag
operation and the gdk
nit: GDK

http://codereview.chromium.org/1084003/diff/2001/3003
File chrome/browser/gtk/tab_contents_drag_source.cc (right):

http://codereview.chromium.org/1084003/diff/2001/3003#newcode53
chrome/browser/gtk/tab_contents_drag_source.cc:53:
reinterpret_cast<gpointer>(OnDragDataGetThunk), this);
I think you need to connect to the drag-data-delete signal now.

http://codereview.chromium.org/1084003/diff/2001/3003#newcode74
chrome/browser/gtk/tab_contents_drag_source.cc:74: WebKit::WebDragOperationsMask
allowed_ops) {
you'll have to sync this with my drag image change. sorry.

http://codereview.chromium.org/1084003/diff/2001/3006
File chrome/browser/tab_contents/web_drag_dest_gtk.cc (right):

http://codereview.chromium.org/1084003/diff/2001/3006#newcode186
chrome/browser/tab_contents/web_drag_dest_gtk.cc:186:
GdkDragActionToWebDragOp(context->actions));
I think you have to set the action of the drag context so that the source knows
whether to take further action or not (i.e. the difference between a move and
copy). How do we know which action webkit picks? Is this what you meant when you
said you need to make webkit changes as well?

[tony, 2010-03-19 01:45:09]

http://codereview.chromium.org/1084003/diff/2001/3002
File app/gtk_dnd_util.h (right):

http://codereview.chromium.org/1084003/diff/2001/3002#newcode81
app/gtk_dnd_util.h:81: // Convenience method for converting between a web drag
operation and the gdk
On 2010/03/18 15:35:36, Evan Stade wrote:
> nit: GDK

Done.

http://codereview.chromium.org/1084003/diff/2001/3003
File chrome/browser/gtk/tab_contents_drag_source.cc (right):

http://codereview.chromium.org/1084003/diff/2001/3003#newcode53
chrome/browser/gtk/tab_contents_drag_source.cc:53:
reinterpret_cast<gpointer>(OnDragDataGetThunk), this);
On 2010/03/18 15:35:36, Evan Stade wrote:
> I think you need to connect to the drag-data-delete signal now.

I'm sorry, I don't understand.  Why?

http://codereview.chromium.org/1084003/diff/2001/3003#newcode74
chrome/browser/gtk/tab_contents_drag_source.cc:74: WebKit::WebDragOperationsMask
allowed_ops) {
On 2010/03/18 15:35:36, Evan Stade wrote:
> you'll have to sync this with my drag image change. sorry. 

Done.

http://codereview.chromium.org/1084003/diff/2001/3006
File chrome/browser/tab_contents/web_drag_dest_gtk.cc (right):

http://codereview.chromium.org/1084003/diff/2001/3006#newcode186
chrome/browser/tab_contents/web_drag_dest_gtk.cc:186:
GdkDragActionToWebDragOp(context->actions));
On 2010/03/18 15:35:36, Evan Stade wrote:
> I think you have to set the action of the drag context so that the source
knows
> whether to take further action or not (i.e. the difference between a move and
> copy). How do we know which action webkit picks? Is this what you meant when
you
> said you need to make webkit changes as well?

This code is just passing the valid source actions to webkit (so webkit can
determine what cursor to show).  It doesn't change the state of the drag context
or the state of anything in webkit.

For example, context->actions might be LINK | COPY for a bookmark on the
bookmark bar, but with HTML5 you can set a div to only accept MOVE actions. 
WebKit needs to know the drag source actions so it can send back the "can't
drop" cursor.

[Evan Stade, 2010-03-19 17:06:55]

http://codereview.chromium.org/1084003/diff/2001/3003
File chrome/browser/gtk/tab_contents_drag_source.cc (right):

http://codereview.chromium.org/1084003/diff/2001/3003#newcode53
chrome/browser/gtk/tab_contents_drag_source.cc:53:
reinterpret_cast<gpointer>(OnDragDataGetThunk), this);
On 2010/03/19 01:45:09, tony wrote:
> On 2010/03/18 15:35:36, Evan Stade wrote:
> > I think you need to connect to the drag-data-delete signal now.
> 
> I'm sorry, I don't understand.  Why?

Because if webkit provides COPY | MOVE, the drop destination has to choose
between copy and move; if it chooses copy then whatever the content is should
stay on the page but if it's move then you'd have to tell the page about it so
they know to remove the content (e.g. text). I believe drag-data-delete is the
way you know if they chose MOVE or not.

http://codereview.chromium.org/1084003/diff/2001/3006
File chrome/browser/tab_contents/web_drag_dest_gtk.cc (right):

http://codereview.chromium.org/1084003/diff/2001/3006#newcode186
chrome/browser/tab_contents/web_drag_dest_gtk.cc:186:
GdkDragActionToWebDragOp(context->actions));
On 2010/03/19 01:45:09, tony wrote:
> On 2010/03/18 15:35:36, Evan Stade wrote:
> > I think you have to set the action of the drag context so that the source
> knows
> > whether to take further action or not (i.e. the difference between a move
and
> > copy). How do we know which action webkit picks? Is this what you meant when
> you
> > said you need to make webkit changes as well?
> 
> This code is just passing the valid source actions to webkit (so webkit can
> determine what cursor to show).  It doesn't change the state of the drag
context
> or the state of anything in webkit.
> 
> For example, context->actions might be LINK | COPY for a bookmark on the
> bookmark bar, but with HTML5 you can set a div to only accept MOVE actions. 
> WebKit needs to know the drag source actions so it can send back the "can't
> drop" cursor.

ah right. L71. Nevermind.

[tony, 2010-03-23 00:26:38]

http://codereview.chromium.org/1084003/diff/2001/3003
File chrome/browser/gtk/tab_contents_drag_source.cc (right):

http://codereview.chromium.org/1084003/diff/2001/3003#newcode53
chrome/browser/gtk/tab_contents_drag_source.cc:53:
reinterpret_cast<gpointer>(OnDragDataGetThunk), this);
On 2010/03/19 17:06:56, Evan Stade wrote:
> On 2010/03/19 01:45:09, tony wrote:
> > On 2010/03/18 15:35:36, Evan Stade wrote:
> > > I think you need to connect to the drag-data-delete signal now.
> > 
> > I'm sorry, I don't understand.  Why?
> 
> Because if webkit provides COPY | MOVE, the drop destination has to choose
> between copy and move; if it chooses copy then whatever the content is should
> stay on the page but if it's move then you'd have to tell the page about it so
> they know to remove the content (e.g. text). I believe drag-data-delete is the
> way you know if they chose MOVE or not.

I see.  I think we don't need to implement this because we always pass in FALSE
as the third param to gtk_drag_finish (in web_drag_dest_gtk) so we never
actually perform a "move".  Also, I think webkit will handle the actual delete
in the case of a move for us (e.g., dragging text around within an input box).

[Evan Stade, 2010-03-23 01:07:24]

LGTM with followup bug filed