Details from  http://crbug.com/637242  

"Actually we are handling copy behavior our own to support Image features in LG proprietary ClipTray feature.
Ex: 1. Assume Webview editor has inline image(inserted image into editor). When user select and do copy, system webview copy will not handle Image scenario.
2. User typed some text and inserted one image to editor(image tag path file://..../data/....../sample.png). In this case if user selects both text and image, only text is copied with system webview default copy).

In these two cases, webview will copy html content and plain text to clipboard but not as different clip items(i.e html content, plain text, image uri, plain text...etc). Because of this, user cannot copy image from webview editor."

Hmm, the mention of "LG proprietary ClipTray" makes me wonder if this it's possible for us to support this with official public APIs?  We would not consider doing this if it requires private APIs.

I have the same problem with drag and drop images and other files: we need support from Android platform.

https://developer.android.com/reference/android/content/ClipData.Item.html
Copy and paste operations use ClipData.Item and it does not support files. The closest thing is a URI, which means the WebView app has to temporarily put the file into a content provider (but WebView does not have one, because a content provider has to declared in the application's manifest), in order for another app to paste. And even then, the app that's pasted into has to understand how to read from the URI.

Images can be represented as base64-encoded data:// URLs.  This can cause perf problems because a lot of systems don't expect to encounter megabyte-sized URLs, but it's a common workaround in this type of situation.

That might work for small images, assuming the destination app knows to decode the data:// back to an image.
But ClipData has an upper limit of 1Mb (I think), which is binder's limit in Android.

In fact, if I try to copy a very large piece of text (like the buildbot output page), then I would get "failed to copy to clipboard" in the toast, and "FAILED BINDER TRANSACTION" in the logcat.

Is the plan to make it possible for LG to use the HTML5 APIs for this eventually?

My plan is that LG would eventually not need to write any code or use any API at all to support this.  When selecting a contenteditable containing an image, Chromium's native selection ought to just paste the image into the Android clipboard properly.  What LG Email app has today is a giant blob of JS and Java workarounds to implement this missing feature themselves.

aelias@ - Android Clipboard currently, don't have direct support of hosting an image. We can write the image in file system and share the content URL to the target app for reading it. Problem is most of the app, is directly expecting text or html format, but not image format from clipboard. Just thought to share this info in this context.

Hmm, cost/benefit doesn't seem to be there for this feature as it's not that clean and the workarounds do work (and it's probably hard to totally break compatibility with these already shipped workarounds in any case so the benefit of the replacement is mild).