Sorry for the title, my miss.
This is surely a UI problem not a Clipboard problem.
It's a Hi-DPI context menu click issue.

I have this problem too. 4k primary screen, 1600x1200 secondary screen, Windows 10  Chrome Version 55.0.2883.44 beta (64-bit). Right-click on an image, click Copy Image, but Chrome doesn't put anything into the clipboard. Previous clipboard contents persists. 

Yes, this is an UI>HiDPI issue. The title is my miss, I copied it from my Vivaldi forum post.
I asked my friend that use a 5K monitor, he had the same issue in 200% DPI mode.
For I'm not a Chromium Developer, I also ask my developer friend, he expects that this is maybe a UI Library issue.

Tagging with current canary Milestone for triaging purpose.

Unable to reproduce the issue on windows 10 Dell laptop with 3640*2160 resolution and page zoom to 175 % .

Note:
High Resolution Monitor like 4K , is not available with inhouse team . Could any one from MTV team look into this.

Thanks !

no, not page zoom to 175%
set your windows dpi to 175%

and page zoom use 100%

Using the old bisect script providing the bisect results,
Good Build : 54.0.2793.0 (Revision :404564)
Bad Build : 54.0.2795.0 (Revision :405182)

You are probably looking for a change made after 404913 (known good), but no later than 404914 (first known bad).

CHANGELOG URL:

 https://chromium.googlesource.com/chromium/src/+log/687d7248d07c24b9c6a5da4e9ee5c4dd939f16e9..29c2239ba264381a4e87d22af15f5fc442d36a40

suspecting the following CL and adding in CC 

@pmonette - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.

Review-Url: https://codereview.chromium.org/2139753002

Thanks!

Hi, I have a retriage and make a GIF, and I try another way.

First, set Windows system DPI to 175% in control panel ( the new UWP setting), startup Chrome, it's OK in my VM ( but not OK in my main pc ), then change Windows system DPI to 200% not restart system, Chrome will get this issue. After that change DPI back to 175%, this issue will be still exist. I don't know why, but it will not be retriaged some time in my VM clean Windows10 testing.

Deleted: bugretriage.gif 1.5 MB

	bugretriage.gif 1.5 MB View Download

I don't know whether another strange thing will influence this issue.
If I startup Chrome with last time webpage, just like Google+, then I copy an image in one post ( not the first post ), it sometimes will copy the first image in the first post.
I don't know whether this will be helpful to this issue.

Oh, another thing.
I use two monitor, one 4K main with 175% DPI connect with MHL-HDMI, one 1920*1200 sub with 100% DPI connect with DVI. If I drag Chrome to the sub monitor, copy image will be fine.

This bug exists from Stable 54.0.2840.71 to latest 57.0.2936.0.
It is very easy to reproduce, so there should be many users already encountered.
Add command line "--force-device-scale-factor=1.25" or set system DPI to 125%, maximize browser window, open https://www.google.com/ncr and right click on the left half of Google logo, select "Copy image".
Nothing copied, "frame()->editor().copyImage(result)" is not called in WebLocalFrameImpl::copyImageAt.
There should be some incorrect coordinate transformation, it is not fault of clipboard writer.

Deleted: copy_image_bad.gif 192 KB

	copy_image_bad.gif 192 KB View Download

Oh, thank you above very much. Exactly the issue it is.
This is not a Clipboard issue that I said above, the title is my fault, I copied it from my Vivaldi forum post.

I might know what the problem is here, I'll take a look. I don't think the above bisect is correct.

Thanks.
I don't exactly know what the truth is, but it acts just like the same as above.
I'm glad to see you clearly know what the issue is.

 Issue 659600  has been merged into this issue.

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

commit 9e97b2c8a89e7a89003906b5e11a30a6260a4099
Author: bsep <bsep@chromium.org>
Date: Wed Dec 21 01:30:23 2016

Fix context menu "Copy image" not working sometimes at hidpi.

Coordinate conversion was happening from viewport->window when opening
the context menu, but not the other direction when asking to copy an
image. Also fixes the same issue when using "Download image" on a
<canvas> (using "Download image" on an <img> uses a different codepath).

R=esprehn@chromium.org
TEST=Right-click the top-left corner of an image and select "Copy image"
     with dsf>1. The image should be copied correctly.
BUG= 667223 

Review-Url: https://codereview.chromium.org/2541423003
Cr-Commit-Position: refs/heads/master@{#439966}

[modify] https://crrev.com/9e97b2c8a89e7a89003906b5e11a30a6260a4099/content/renderer/render_frame_impl.cc

 Issue 659776  has been merged into this issue.

Your change meets the bar and is auto-approved for M56 (branch: 2924)

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

commit 8e2afdfc4f366d9b010f10ad058fa1e072f037e7
Author: Bret Sepulveda <bsep@chromium.org>
Date: Tue Jan 03 23:43:03 2017

Fix context menu "Copy image" not working sometimes at hidpi.

Coordinate conversion was happening from viewport->window when opening
the context menu, but not the other direction when asking to copy an
image. Also fixes the same issue when using "Download image" on a
<canvas> (using "Download image" on an <img> uses a different codepath).

R=esprehn@chromium.org
TEST=Right-click the top-left corner of an image and select "Copy image"
     with dsf>1. The image should be copied correctly.
BUG= 667223 

Review-Url: https://codereview.chromium.org/2541423003
Cr-Commit-Position: refs/heads/master@{#439966}
(cherry picked from commit 9e97b2c8a89e7a89003906b5e11a30a6260a4099)

Review-Url: https://codereview.chromium.org/2609233003 .
Cr-Commit-Position: refs/branch-heads/2924@{#660}
Cr-Branched-From: 3a87aecc31cd1ffe751dd72c04e5a96a1fc8108a-refs/heads/master@{#433059}

[modify] https://crrev.com/8e2afdfc4f366d9b010f10ad058fa1e072f037e7/content/renderer/render_frame_impl.cc

Thank you, bsep.
I can confirm this bug is fixed now.

Tested the issue on Win 10.0 using chrome latest beta #56.0.2924.51 by following steps mentioned in original comment.Observed that copied images are displaying as expected.Hence adding TE-Verified label.
Please find the screen shot for reference

Thank you!

Please find the Screen shot.

Deleted: 667223.PNG 4.4 MB

	667223.PNG 4.4 MB View Download

Issue 699810 has been merged into this issue.