We're cutting M51 Stable candidate tomorrow. We need to have fix landed in tonight's Canary, and merged to M51 branch 2704 before 4:00 PM PST tomorrow once it is baked/verified in canary.

Able to reproduce the issue and working on the bisect now will update the results soon.

I've attached screenshots of the actual contents of the clipboard. In M52, we now add more contents to the clipboard, but it appears that "Finder->Edit->ShowClipboard" prefers to show the URL rather than the image.

I don't know why Docs chooses to pick up the URL instead of the image [whether this is a Chrome or Docs bug].

Deleted: Screen Shot 2016-05-23 at 10.54.44 AM.png 58.6 KB

	Screen Shot 2016-05-23 at 10.54.44 AM.png 58.6 KB View Download

Deleted: Screen Shot 2016-05-23 at 10.54.22 AM.png 11.0 KB

	Screen Shot 2016-05-23 at 10.54.22 AM.png 11.0 KB View Download

We had a similar problem with writing markup to the clipboard for images in the past: see https://chromium.googlesource.com/chromium/src/+/master/content/renderer/webclipboard_impl.cc#164 and https://bugs.chromium.org/p/chromium/issues/detail?id=33016.

My guess is that different Mac applications (and Chrome itself) are very inconsistent about the order in which they read the different data types shoved into the clipboard.

I bet that this is triggered by one of my recent changes to the way that Chrome handles the pasteboard in general [we now shove more data into it, rather than less, as you can observe]. Let's wait for pbommana to find out exactly which CL regressed this behavior.

Note that the actual logic of WebClipboardImpl::WriteImage() implies that we should be writing both the image and the URL:
https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/webclipboard_impl.cc&q=WebClipboardImpl::writeImage&sq=package:chromium&type=cs&l=154

It looks like our behavior now matches Safari's behavior, at least in terms of what we shove into the Clipboard. Safari also shows up as a URL in Finder > Edit > ShowClipboard. Note that there's a different order for the TIFFs, although I don't think order matters.

When I try to paste from Safari into Google Docs in Chrome, a URL is pasted rather than an image.

When I try to past from Safari into Google Docs in Safari, nothing is pasted.

Deleted: Screen Shot 2016-05-23 at 11.12.57 AM.png 49.4 KB

	Screen Shot 2016-05-23 at 11.12.57 AM.png 49.4 KB View Download

Bisect Result :
You are probably looking for a change made after 384732 (known good), but no later than 384762 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/bd4c6ac99e771e0d5893b25d8058d3153efb6fa1..d4e8c65ad84d47cbd436d05d7ec5393bd68194f9

Here's a summary of the bug:

1. Chrome used to put not very much metadata into the clipboard.
2. My CL (in #7) adds more metadata to the clipboard and also starts to remove all the redundant and inconsistent code Chrome uses to interact with the clipboard. This causes Chrome to behave more like Safari and other system apps.
3. This broke Chrome's interaction with Google Docs. The exact reason is unclear. It's possible that Chrome is incorrectly exposing the text instead of the image. It's possible Google Docs sees both pieces of metadata, and chooses to use the text instead. 

Someone needs to research (3) and determine an appropriate course of action. While I'm not super happy about introducing this bug to Chrome, there is no way that this will be fixed by today. I also don't think this is a Pri-1, RB-S. spqchan@ has graciously indicated that she is willing to take a look at this.

Thanks everyone for digging in so quickly. Who on the Docs team can we rope in to help answer questions?

Issue 617119 has been merged into this issue.

I started looking over this and it looks like Erik's suspicion that Docs is choosing the text over the image is correct. His CL adds plain-text metadata to the clipboard when you copy the image, which is picked up by Docs. 

This makes it more of a Docs issue instead of a Chrome one, since it looks like other websites are able to pick up the image probably. Ex/ If you copy and paste the image on pasteboard.co, the website picks up the image instead of the text.

I played around with the clipboard and found that the image shows up properly on Docs if the plain-text metadata is removed.

We should test that various native apps handle this correctly, now that the default APIs will write text to the pasteboard? I think that should be true, but it'd be good to confirm: in the past, we explicitly avoided doing this specifically because of app compat concerns: see https://chromium.googlesource.com/chromium/src/+/master/content/renderer/webclipboard_impl.cc#164

I'm guessing that that comment is out of date? As I mentioned in https://bugs.chromium.org/p/chromium/issues/detail?id=614055#c6, Chrome now behaves more similarly to other native apps.

Fyi, I contacted docs-eng about this issue and they have a couple of people that will look into it now

Right, assuming other apps are all behaving like this (Safari, Firefox), then we should update the historical context of that comment as well.

Bug from Docs team: https://buganizer.corp.google.com/u/0/issues/2925151

Wrong bug:

https://buganizer.corp.google.com/u/0/issues/29251511

This issue is fixed by the Docs team

Great!

Not sure if there's another bug for this but the same issue appears to be happening  recently in gmail:

Copy Image -> Paste into gmail compose:  the URL pastes rather than the image
Screenshot -> Paste into gmail compose:  the images pastes, as expected

The issue in c#22 is slightly different - in that case you're saying the URL is pasting in, but for me I'm getting what looks to be MIME data (not a URL).

Sorry - please ignore c#23. There was another image pasting bug that I read this morning. I thought I was back on that bug.

For this, we should look if it works on Safari or Mozilla. It's possible that like Docs, it's an issue with Gmail

Tried on Safari and it's a bit weird? Not sure if it's intentional.
I'll open a new bug for this and see if I can file a bug with Gmail to see if it's intentional

Deleted: Screen Shot 2016-10-27 at 1.47.20 PM.png 26.9 KB

	Screen Shot 2016-10-27 at 1.47.20 PM.png 26.9 KB View Download

See  Issue 660147