Note that there's a minor privacy implication of the current behavior (on all platforms) in that a user who has performed a "Copy Image" operation and then pastes it into a website may not be expecting that the original source URL is exposed to that website.

Related to  issue 33016 

A little more debugging on the copying side:

Per  issue 33016  - https://cs.chromium.org/chromium/src/content/renderer/webclipboard_impl.cc?l=183

"When writing the image, we also write the image markup so that pasting into rich text editors, such as Gmail, reveals the image."

but:

"We also don't want to write HTML on a Mac, since Mail.app prefers to use the image markup over attaching the actual image."

But we do call WriteBookmark(url, title) on all platforms, which IPCs over into:

https://cs.chromium.org/chromium/src/ui/base/clipboard/scoped_clipboard_writer.cc?type=cs&l=59

... which bails early if title is empty.

So we get this matrix of types on the clipboard after the copy:

* No ALT:
  * Mac: bitmap
  * Other: bitmap, html
* With ALT:
  * Mac: bitmap, bookmark
  * Other: bitmap, bookmark, html

... and then on the paste event side (shown as: kind;type)

* No ALT:
  * Mac: file;image/png
  * Other: string;text/html, file;image/png
* With ALT:
  * Mac: string;text/plain, file;image/png
  * Other: string;text/html, file;image/png

Where the text/plain string in the Mac+ALT case is the URL, and that's what web apps paste. They could select the image instead.

Re #5: Indeed, they /can/ (e.g. Google Docs does); the problem is that a non-trivial set /do not/ pick the image (e.g. classic GMail, Twitter).

Re: #6: Agreed, yeah. Our follow-ups collided:

I'm tempted to recommend we drop populating "bookmark" for images, either Mac-only or everywhere, but I defer to the clipboard experts.

Not populating bookmark on Mac seems reasonable to me, assuming it doesn't break anything. Would this also solve  issue 694548 ?

Alternately, we could leave copy alone, but not produce string;text/plain from bookmark on paste if-and-only-if there's also image content.

That would ensure we don't break copy/paste chrome -> native, but the behavior there is perhaps more mysterious.

I'll see about a CL for just dropping bookmark on mac, not sure how to gauge the impact though.

Sorry for not getting to closure with this. I ran into flakiness in the test on Windows which I have not yet resolved, and higher priority items have come up.

Patch is just waiting for an OWNERS review now.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/7c4e86a20a7a14dca766799966d2c9fe5b919b3e

commit 7c4e86a20a7a14dca766799966d2c9fe5b919b3e
Author: Joshua Bell <jsbell@chromium.org>
Date: Thu Dec 07 19:28:15 2017

Mac/Clipboard/Images - only populate bookmark if also populating HTML

When copying an image (right click > Copy Image) we populate the
clipboard with a bitmap and additionally with markup ("<img
src=cat.gif>")... except on MacOS where the markup confuses native
apps (per  https://crbug.com/33016 ).

Additionally, if an ALT attribute is present, we populate the
clipboard with a "bookmark" (text/url pair). This is unlikely to be
used in general, but when pasting back into Chrome it would be present
in the transfer data as text/plain string of the URL, if-and-only-if
the transfer data did not include a text/html string. Per the above
paragraph, this only happens on MacOS.

Some Web applications (including Gmail) prefer to paste the string
rather than the image. Result: On MacOS, copying and pasting an image
with an ALT tag produces a URL instead of the copied image.

This CL mitigates the above problem by only populating a "bookmark"
if populating markup as well.

Bug:  736439 
Change-Id: I831d785940d561d5928183b35e3c3fe27cf387ab
Reviewed-on: https://chromium-review.googlesource.com/565328
Commit-Queue: Joshua Bell <jsbell@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Victor Costan <pwnall@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522506}
[modify] https://crrev.com/7c4e86a20a7a14dca766799966d2c9fe5b919b3e/content/renderer/webclipboard_impl.cc
[modify] https://crrev.com/7c4e86a20a7a14dca766799966d2c9fe5b919b3e/content/renderer/webclipboard_impl_browsertest.cc
[add] https://crrev.com/7c4e86a20a7a14dca766799966d2c9fe5b919b3e/content/test/data/image_copy_types.html

 Issue 694548  has been merged into this issue.