Support dragging texts out of webview/Chrome.

Support dragging texts out of webview/Chrome.

With this CL, the user is able to drag the selected text from WebView/Chrome to
other apps (Copy operation) or within the same WebView/Chrome tab (Move
operation).

This feature is disabled by default until we fully test it, and can be enabled
by "switches::kEnableTouchDragDrop".

BUG=584789
Committed: https://crrev.com/a100bde7399e5876e0ff61ac176b255eb6cf7e95
Cr-Commit-Position: refs/heads/master@{#406105}

[hush (inactive), 2016-07-08 00:29:48]

hush@chromium.org changed reviewers:
+ dcheng@chromium.org

[hush (inactive), 2016-07-08 00:29:48]

Hello Daniel,
Can you take a look first?
Thanks!

[hush (inactive), 2016-07-08 02:30:16]

Patchset #1 (id:1) has been deleted

[hush (inactive), 2016-07-08 02:36:03]

Patchset #1 (id:20001) has been deleted

[hush (inactive), 2016-07-08 02:38:55]

Vlad FYI

[dcheng, 2016-07-08 06:30:30]

Code changes seems reasonable, but I'm not an owner =)

https://codereview.chromium.org/2135493002/diff/40001/content/browser/web_con...
File content/browser/web_contents/web_contents_view_android.cc (right):

https://codereview.chromium.org/2135493002/diff/40001/content/browser/web_con...
content/browser/web_contents/web_contents_view_android.cc:213:
blink::WebDragOperationMove);
Out of curiosity, why did we change this from Copy to Copy+Move?

[hush (inactive), 2016-07-08 18:23:25]

https://codereview.chromium.org/2135493002/diff/40001/content/browser/web_con...
File content/browser/web_contents/web_contents_view_android.cc (right):

https://codereview.chromium.org/2135493002/diff/40001/content/browser/web_con...
content/browser/web_contents/web_contents_view_android.cc:213:
blink::WebDragOperationMove);
On 2016/07/08 06:30:30, dcheng wrote:
> Out of curiosity, why did we change this from Copy to Copy+Move?

The move operation is to support dragging texts within the same chrome tab or
the same webview. Android TextView does this too: when you drag within the same
view, it's gonna be a move, otherwise a copy.

So if I don't allow move here, WebViewImpl::dragTargetDrop will just early out
(because blink wants to move the text but wasn't allowed to do so, as a result,
m_dragOperation in WebViewImpl is set to WebDragOperationNone)
See here
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/web/WebViewImp...

[hush (inactive), 2016-07-08 18:28:50]

hush@chromium.org changed reviewers:
+ sievers@chromium.org, sky@chromium.org, yfriedman@chromium.org

[hush (inactive), 2016-07-08 18:28:50]

Hello Yaron,
PTAL content/browser/android* and content/public/android/*

sievers@
PTAL content/browser/web_contents/*

sky@:
PTAL ui/base

[hush (inactive), 2016-07-08 20:16:03]

hush@chromium.org changed reviewers:
- sky@chromium.org

[hush (inactive), 2016-07-08 20:17:02]

Description was changed from

==========
Support dragging texts out of webview/Chrome.

With this CL, the user is able to drag the selected text from WebView/Chrome to
other apps (Copy operation) or within the same WebView/Chrome tab (Move
operation).

This feature can be disabled with flag "switches::kDisableTouchDragDrop".

BUG=584789
==========

to

==========
Support dragging texts out of webview/Chrome.

With this CL, the user is able to drag the selected text from WebView/Chrome to
other apps (Copy operation) or within the same WebView/Chrome tab (Move
operation).

This feature is disabled by default until we fully test it, and can be enabled
by "switches::kEnableTouchDragDrop".
    

BUG=584789
==========

[no sievers, 2016-07-11 18:48:10]

Please don't add any more code in ContentViewCore since it's deprecated.

Can you add it in one of the existing public interfaces (like WebContents, RWHV)
wherever it fits best?

[no sievers, 2016-07-11 18:51:52]

On 2016/07/11 18:48:10, sievers wrote:
> Please don't add any more code in ContentViewCore since it's deprecated.
> 
> Can you add it in one of the existing public interfaces (like WebContents,
RWHV)
> wherever it fits best?

Sorry, I missed that this flows the other way.
Since it originates in WebContentsView, I think forwarding it up through
WebContentsViewDelegate makes sense which WebView already implements.

[hush (inactive), 2016-07-11 20:15:49]

On 2016/07/11 18:51:52, sievers wrote:
> On 2016/07/11 18:48:10, sievers wrote:
> > Please don't add any more code in ContentViewCore since it's deprecated.
> > 
> > Can you add it in one of the existing public interfaces (like WebContents,
> RWHV)
> > wherever it fits best?
> 
> Sorry, I missed that this flows the other way.
> Since it originates in WebContentsView, I think forwarding it up through
> WebContentsViewDelegate makes sense which WebView already implements.


What about the other way (dragging *into* webview/chrome)? 
https://codereview.chromium.org/2113183003/
Currently the plumbing for dragging in is from ContentView --> ContentViewCore
--> WebContentsViewAndroid.
ContentView is the view that gets "onDragEvent" callbacks from Android. 

It feels weird that the plumbing in 2 directions are in 2 different objects
(ContentViewCore vs WebContentsViewDelegate)

[no sievers, 2016-07-11 20:56:49]

On 2016/07/11 20:15:49, hush wrote:
> On 2016/07/11 18:51:52, sievers wrote:
> > On 2016/07/11 18:48:10, sievers wrote:
> > > Please don't add any more code in ContentViewCore since it's deprecated.
> > > 
> > > Can you add it in one of the existing public interfaces (like WebContents,
> > RWHV)
> > > wherever it fits best?
> > 
> > Sorry, I missed that this flows the other way.
> > Since it originates in WebContentsView, I think forwarding it up through
> > WebContentsViewDelegate makes sense which WebView already implements.
> 
> 
> What about the other way (dragging *into* webview/chrome)? 
> https://codereview.chromium.org/2113183003/
> Currently the plumbing for dragging in is from ContentView --> ContentViewCore
> --> WebContentsViewAndroid.
> ContentView is the view that gets "onDragEvent" callbacks from Android. 
> 
> It feels weird that the plumbing in 2 directions are in 2 different objects
> (ContentViewCore vs WebContentsViewDelegate)

Yes, but the problem is that there are multiple objects that are potentially
responsible for this in the first place :)

Hence making ContentViewCore go away - it's a superclass with no clear semantics
and instead seeing what can move into ViewAndroid, WebContentsViewAndroid,
RWHVAndroid, or to the embedder or other feature modules as appropriate.

For this: Maybe that could be similar do desktop, see for example
WebContentsViewAura::OnPerformDrop() which implements a delegate API for
receiving this.

As far as where it's forwarded *from* is concerned:
On Android it looks similar to the stuff we do for onTouchEvent() since it's an
event from the Java View.
(Basically this is JNI-related stuff that mostly converts the Java arguments to
what the native APIs need.)
So we could just do this like crbug.com/622847 then and route it through
ViewAndroid, which then delegates it to WebContentsViewAndroid.

When ContentViewCore goes away, the WebContentsViewAndroid will own the
ViewAndroid that CVC currently 'owns' (or 'was' until
https://codereview.chromium.org/2122403002/).

Eventually I was thinking all this event forwarding for WebView, Clank and Blimp
could work like this:

Each of them uses some static shared helper code to convert the Java structs and
calls into native (AwContents or so? I don't know...) where it forwards it to
the native ViewAndroid::OnXXXEvent(). That calls into some sort of delegate
interface which is implemented by WebContentsView and RenderWidgetHostView etc..

Drag could also be routed from some other object (like some drag controller or
so) to the WCVAndroid instead of going through the ViewAndroid. (It doesn't even
have to go through WCVAndroid since all the APIs are already exposed publically
through RWH so the sender could also bypass it.)

Let me know what you think. Maybe this discussion should actually move into some
bug, but good point about sorting onDragEvent() out also - it'd be great to also
get this out of ContentViewCore.

[hush (inactive), 2016-07-11 21:52:47]

On 2016/07/11 20:56:49, sievers wrote:
> On 2016/07/11 20:15:49, hush wrote:
> > On 2016/07/11 18:51:52, sievers wrote:
> > > On 2016/07/11 18:48:10, sievers wrote:
> > > > Please don't add any more code in ContentViewCore since it's deprecated.
> > > > 
> > > > Can you add it in one of the existing public interfaces (like
WebContents,
> > > RWHV)
> > > > wherever it fits best?
> > > 
> > > Sorry, I missed that this flows the other way.
> > > Since it originates in WebContentsView, I think forwarding it up through
> > > WebContentsViewDelegate makes sense which WebView already implements.
> > 
> > 
> > What about the other way (dragging *into* webview/chrome)? 
> > https://codereview.chromium.org/2113183003/
> > Currently the plumbing for dragging in is from ContentView -->
ContentViewCore
> > --> WebContentsViewAndroid.
> > ContentView is the view that gets "onDragEvent" callbacks from Android. 
> > 
> > It feels weird that the plumbing in 2 directions are in 2 different objects
> > (ContentViewCore vs WebContentsViewDelegate)
> 
> Yes, but the problem is that there are multiple objects that are potentially
> responsible for this in the first place :)
> 
> Hence making ContentViewCore go away - it's a superclass with no clear
semantics
> and instead seeing what can move into ViewAndroid, WebContentsViewAndroid,
> RWHVAndroid, or to the embedder or other feature modules as appropriate.
> 
> For this: Maybe that could be similar do desktop, see for example
> WebContentsViewAura::OnPerformDrop() which implements a delegate API for
> receiving this.
> 
> As far as where it's forwarded *from* is concerned:
> On Android it looks similar to the stuff we do for onTouchEvent() since it's
an
> event from the Java View.
> (Basically this is JNI-related stuff that mostly converts the Java arguments
to
> what the native APIs need.)
> So we could just do this like crbug.com/622847 then and route it through
> ViewAndroid, which then delegates it to WebContentsViewAndroid.
> 
> When ContentViewCore goes away, the WebContentsViewAndroid will own the
> ViewAndroid that CVC currently 'owns' (or 'was' until
> https://codereview.chromium.org/2122403002/).
> 
> Eventually I was thinking all this event forwarding for WebView, Clank and
Blimp
> could work like this:
> 
> Each of them uses some static shared helper code to convert the Java structs
and
> calls into native (AwContents or so? I don't know...) where it forwards it to
> the native ViewAndroid::OnXXXEvent(). That calls into some sort of delegate
> interface which is implemented by WebContentsView and RenderWidgetHostView
etc..
> 
> Drag could also be routed from some other object (like some drag controller or
> so) to the WCVAndroid instead of going through the ViewAndroid. (It doesn't
even
> have to go through WCVAndroid since all the APIs are already exposed
publically
> through RWH so the sender could also bypass it.)
> 
> Let me know what you think. Maybe this discussion should actually move into
some
> bug, but good point about sorting onDragEvent() out also - it'd be great to
also
> get this out of ContentViewCore.

Hi Daniel, I opened crbug.com/627246 for it.
I'm still digesting this whole refactor thing.

A question:
so before this big refactor, ContentViewCore is common entry point for both
Android WebView and Chrome for events like drag, touch, motion. What will be the
common entry point after the refactor? Is it just "ViewAndroid" object? And who
will own WebContentsViewAndroid?

[no sievers, 2016-07-11 21:58:50]

On 2016/07/11 21:52:47, hush wrote:
> On 2016/07/11 20:56:49, sievers wrote:
> > On 2016/07/11 20:15:49, hush wrote:
> > > On 2016/07/11 18:51:52, sievers wrote:
> > > > On 2016/07/11 18:48:10, sievers wrote:
> > > > > Please don't add any more code in ContentViewCore since it's
deprecated.
> > > > > 
> > > > > Can you add it in one of the existing public interfaces (like
> WebContents,
> > > > RWHV)
> > > > > wherever it fits best?
> > > > 
> > > > Sorry, I missed that this flows the other way.
> > > > Since it originates in WebContentsView, I think forwarding it up through
> > > > WebContentsViewDelegate makes sense which WebView already implements.
> > > 
> > > 
> > > What about the other way (dragging *into* webview/chrome)? 
> > > https://codereview.chromium.org/2113183003/
> > > Currently the plumbing for dragging in is from ContentView -->
> ContentViewCore
> > > --> WebContentsViewAndroid.
> > > ContentView is the view that gets "onDragEvent" callbacks from Android. 
> > > 
> > > It feels weird that the plumbing in 2 directions are in 2 different
objects
> > > (ContentViewCore vs WebContentsViewDelegate)
> > 
> > Yes, but the problem is that there are multiple objects that are potentially
> > responsible for this in the first place :)
> > 
> > Hence making ContentViewCore go away - it's a superclass with no clear
> semantics
> > and instead seeing what can move into ViewAndroid, WebContentsViewAndroid,
> > RWHVAndroid, or to the embedder or other feature modules as appropriate.
> > 
> > For this: Maybe that could be similar do desktop, see for example
> > WebContentsViewAura::OnPerformDrop() which implements a delegate API for
> > receiving this.
> > 
> > As far as where it's forwarded *from* is concerned:
> > On Android it looks similar to the stuff we do for onTouchEvent() since it's
> an
> > event from the Java View.
> > (Basically this is JNI-related stuff that mostly converts the Java arguments
> to
> > what the native APIs need.)
> > So we could just do this like crbug.com/622847 then and route it through
> > ViewAndroid, which then delegates it to WebContentsViewAndroid.
> > 
> > When ContentViewCore goes away, the WebContentsViewAndroid will own the
> > ViewAndroid that CVC currently 'owns' (or 'was' until
> > https://codereview.chromium.org/2122403002/).
> > 
> > Eventually I was thinking all this event forwarding for WebView, Clank and
> Blimp
> > could work like this:
> > 
> > Each of them uses some static shared helper code to convert the Java structs
> and
> > calls into native (AwContents or so? I don't know...) where it forwards it
to
> > the native ViewAndroid::OnXXXEvent(). That calls into some sort of delegate
> > interface which is implemented by WebContentsView and RenderWidgetHostView
> etc..
> > 
> > Drag could also be routed from some other object (like some drag controller
or
> > so) to the WCVAndroid instead of going through the ViewAndroid. (It doesn't
> even
> > have to go through WCVAndroid since all the APIs are already exposed
> publically
> > through RWH so the sender could also bypass it.)
> > 
> > Let me know what you think. Maybe this discussion should actually move into
> some
> > bug, but good point about sorting onDragEvent() out also - it'd be great to
> also
> > get this out of ContentViewCore.
> 
> Hi Daniel, I opened crbug.com/627246 for it.
> I'm still digesting this whole refactor thing.
> 
> A question:
> so before this big refactor, ContentViewCore is common entry point for both
> Android WebView and Chrome for events like drag, touch, motion. What will be
the
> common entry point after the refactor? Is it just "ViewAndroid" object? And
who
> will own WebContentsViewAndroid?

I think ViewAndroid at least for touch events and setting size and visibility of
the contents (probably a few more things).
(One goal related to that is also to allow Blimp to share some of the code for
delegated rendering and touch handling without it having a WebContents or
ContentViewCore. Another one is to rid the contextual search overlay panel of
its fake ContainerView that it needs to supply - at least with the way the code
currently works.)

Some things might also just move to WebContents. And a few WebView
implementation details that have made it into ContentViewCore I'd like to move
up to android_webview/, also see https://codereview.chromium.org/2103243002/.

[hush (inactive), 2016-07-12 21:46:29]

Patchset #3 (id:80001) has been deleted

[hush (inactive), 2016-07-12 21:49:06]

Patchset #3 (id:100001) has been deleted

[hush (inactive), 2016-07-12 21:49:56]

Hello sievers@, PTAL

[no sievers, 2016-07-12 23:34:06]

On 2016/07/12 21:49:56, hush wrote:
> Hello sievers@, PTAL

lgtm

[hush (inactive), 2016-07-13 19:11:08]

The CQ bit was checked by hush@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-07-13 19:13:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-13 20:13:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-07-13 20:13:40]

Dry run: This issue passed the CQ dry run.

[hush (inactive), 2016-07-13 21:25:10]

hush@chromium.org changed reviewers:
+ twellington@chromium.org

[hush (inactive), 2016-07-13 21:25:14]

Hello Theresa,
PTAL ui/android

[Theresa, 2016-07-13 22:55:42]

Having reviewed none of the other drag and drop code, I think this looks good.
Any reason this can't wait until next week when tedchoc@ is back?

https://codereview.chromium.org/2135493002/diff/140001/content/public/android...
File
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
(right):

https://codereview.chromium.org/2135493002/diff/140001/content/public/android...
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:315:
containerView.startDrag(
This method is deprecated in API 24, so there will likely be lint warnings for
anyone building against the new API. Right now lint warnings don't do anything
but eventually we'd like to treat warnings as errors. Will you please suppress
the warning?

https://codereview.chromium.org/2135493002/diff/140001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/base/ViewAndroidDelegate.java (right):

https://codereview.chromium.org/2135493002/diff/140001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/base/ViewAndroidDelegate.java:38: * @param
text the dragged text.
nit: capitalize "The" here and a below

[sgurun-gerrit only, 2016-07-14 18:13:34]

sgurun@chromium.org changed reviewers:
+ sgurun@chromium.org

[sgurun-gerrit only, 2016-07-14 18:13:35]

https://codereview.chromium.org/2135493002/diff/140001/content/browser/web_co...
File content/browser/web_contents/web_contents_view_android.cc (right):

https://codereview.chromium.org/2135493002/diff/140001/content/browser/web_co...
content/browser/web_contents/web_contents_view_android.cc:222:
native_view->StartDragAndDrop(jtext,
it is better to convert the java type in location where you actually need. It
seems the right place is window_android. Is there any need to do it here?

[hush (inactive), 2016-07-14 18:37:07]

https://codereview.chromium.org/2135493002/diff/140001/content/browser/web_co...
File content/browser/web_contents/web_contents_view_android.cc (right):

https://codereview.chromium.org/2135493002/diff/140001/content/browser/web_co...
content/browser/web_contents/web_contents_view_android.cc:222:
native_view->StartDragAndDrop(jtext,
On 2016/07/14 18:13:35, sgurun wrote:
> it is better to convert the java type in location where you actually need. It
> seems the right place is window_android. Is there any need to do it here?

because window_android is in ui and cannot depend on content/. We need
content::DropData if we were to convert the data to java type here.

[hush (inactive), 2016-07-14 18:42:09]

https://codereview.chromium.org/2135493002/diff/140001/content/public/android...
File
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java
(right):

https://codereview.chromium.org/2135493002/diff/140001/content/public/android...
content/public/android/java/src/org/chromium/content/browser/ContentViewCore.java:315:
containerView.startDrag(
On 2016/07/13 22:55:42, Theresa Wellington wrote:
> This method is deprecated in API 24, so there will likely be lint warnings for
> anyone building against the new API. Right now lint warnings don't do anything
> but eventually we'd like to treat warnings as errors. Will you please suppress
> the warning?

Yes, done.

https://codereview.chromium.org/2135493002/diff/140001/ui/android/java/src/or...
File ui/android/java/src/org/chromium/ui/base/ViewAndroidDelegate.java (right):

https://codereview.chromium.org/2135493002/diff/140001/ui/android/java/src/or...
ui/android/java/src/org/chromium/ui/base/ViewAndroidDelegate.java:38: * @param
text the dragged text.
On 2016/07/13 22:55:42, Theresa Wellington wrote:
> nit: capitalize "The" here and a below

Done.

[sgurun-gerrit only, 2016-07-14 18:43:05]

https://codereview.chromium.org/2135493002/diff/140001/content/browser/web_co...
File content/browser/web_contents/web_contents_view_android.cc (right):

https://codereview.chromium.org/2135493002/diff/140001/content/browser/web_co...
content/browser/web_contents/web_contents_view_android.cc:222:
native_view->StartDragAndDrop(jtext,
On 2016/07/14 18:37:07, hush wrote:
> On 2016/07/14 18:13:35, sgurun wrote:
> > it is better to convert the java type in location where you actually need.
It
> > seems the right place is window_android. Is there any need to do it here?
> 
> because window_android is in ui and cannot depend on content/. We need
> content::DropData if we were to convert the data to java type here.

ok in this case, I am fine.

Daniel:

By converting the data to a java type and passing to WindowAndroid we are making
it opaque to WindowAndroid. In your new design, is the final role for
WindowAndroid being a class just transferring such data to Java side?

[hush (inactive), 2016-07-14 18:43:11]

On 2016/07/13 22:55:42, Theresa Wellington wrote:
> Having reviewed none of the other drag and drop code, I think this looks good.
> Any reason this can't wait until next week when tedchoc@ is back?

Yeah I can wait for tedchoc@ to be back next week.

[no sievers, 2016-07-14 20:31:13]

https://codereview.chromium.org/2135493002/diff/140001/content/browser/web_co...
File content/browser/web_contents/web_contents_view_android.cc (right):

https://codereview.chromium.org/2135493002/diff/140001/content/browser/web_co...
content/browser/web_contents/web_contents_view_android.cc:222:
native_view->StartDragAndDrop(jtext,
On 2016/07/14 18:43:04, sgurun wrote:
> On 2016/07/14 18:37:07, hush wrote:
> > On 2016/07/14 18:13:35, sgurun wrote:
> > > it is better to convert the java type in location where you actually need.
> It
> > > seems the right place is window_android. Is there any need to do it here?
> > 
> > because window_android is in ui and cannot depend on content/. We need
> > content::DropData if we were to convert the data to java type here.
> 
> ok in this case, I am fine.
> 
> Daniel:
> 
> By converting the data to a java type and passing to WindowAndroid we are
making
> it opaque to WindowAndroid. In your new design, is the final role for
> WindowAndroid being a class just transferring such data to Java side? 

I think we'll probably want to eventually just add JNI to ViewAndroid(Delegate),
bypassing WindowAndroid (since this is going to the container view).

[hush (inactive), 2016-07-14 23:43:06]

hush@chromium.org changed reviewers:
+ tedchoc@chromium.org

[hush (inactive), 2016-07-14 23:43:07]

Patch set 6: we discovered a bug in Android N framework: it is possible for
ClipDescription to be null in ACTION_DRAG_EXITED. 
So I relaxed condition checks in ContentViewCore.java

+tedchoc for ui/ review

[sgurun-gerrit only, 2016-07-15 17:14:03]

On 2016/07/14 23:43:07, hush wrote:
> Patch set 6: we discovered a bug in Android N framework: it is possible for
> ClipDescription to be null in ACTION_DRAG_EXITED. 
> So I relaxed condition checks in ContentViewCore.java
> 
> +tedchoc for ui/ review

not an owner in any place here but lgtm

[Ted C, 2016-07-18 20:07:31]

On 2016/07/15 17:14:03, sgurun wrote:
> On 2016/07/14 23:43:07, hush wrote:
> > Patch set 6: we discovered a bug in Android N framework: it is possible for
> > ClipDescription to be null in ACTION_DRAG_EXITED. 
> > So I relaxed condition checks in ContentViewCore.java
> > 
> > +tedchoc for ui/ review
> 
> not an owner in any place here but lgtm

ui - lgtm

[hush (inactive), 2016-07-18 20:23:01]

The CQ bit was checked by hush@chromium.org

[hush (inactive), 2016-07-18 20:23:01]

The patchset sent to the CQ was uploaded after l-g-t-m from sievers@chromium.org
Link to the patchset: https://codereview.chromium.org/2135493002/#ps180001
(title: "Workaround b/30148704")

[commit-bot: I haz the power, 2016-07-18 20:23:35]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-18 21:38:54]

Description was changed from

==========
Support dragging texts out of webview/Chrome.

With this CL, the user is able to drag the selected text from WebView/Chrome to
other apps (Copy operation) or within the same WebView/Chrome tab (Move
operation).

This feature is disabled by default until we fully test it, and can be enabled
by "switches::kEnableTouchDragDrop".
    

BUG=584789
==========

to

==========
Support dragging texts out of webview/Chrome.

With this CL, the user is able to drag the selected text from WebView/Chrome to
other apps (Copy operation) or within the same WebView/Chrome tab (Move
operation).

This feature is disabled by default until we fully test it, and can be enabled
by "switches::kEnableTouchDragDrop".
    

BUG=584789
==========

[commit-bot: I haz the power, 2016-07-18 21:38:55]

Committed patchset #6 (id:180001)

[commit-bot: I haz the power, 2016-07-18 21:39:11]

CQ bit was unchecked.

[commit-bot: I haz the power, 2016-07-18 21:41:56]

Description was changed from

==========
Support dragging texts out of webview/Chrome.

With this CL, the user is able to drag the selected text from WebView/Chrome to
other apps (Copy operation) or within the same WebView/Chrome tab (Move
operation).

This feature is disabled by default until we fully test it, and can be enabled
by "switches::kEnableTouchDragDrop".
    

BUG=584789
==========

to

==========
Support dragging texts out of webview/Chrome.

With this CL, the user is able to drag the selected text from WebView/Chrome to
other apps (Copy operation) or within the same WebView/Chrome tab (Move
operation).

This feature is disabled by default until we fully test it, and can be enabled
by "switches::kEnableTouchDragDrop".

BUG=584789

Committed: https://crrev.com/a100bde7399e5876e0ff61ac176b255eb6cf7e95
Cr-Commit-Position: refs/heads/master@{#406105}
==========

[commit-bot: I haz the power, 2016-07-18 21:41:57]

Patchset 6 (id:??) landed as
https://crrev.com/a100bde7399e5876e0ff61ac176b255eb6cf7e95
Cr-Commit-Position: refs/heads/master@{#406105}