Able to reproduce this issue on reported version 66.0.3359.139 and on latest canary 68.0.3417.0 using Mac 10.12.6. i.e; While copying image and pasting in FB messenger pastes URL instead of image. Attaching screencast for reference.

Good Build: 66.0.3350.0
Bad Build: 66.0.3352.0

You are probably looking for a change made after 537967 (known good), but no later than 537968 (first known bad).
CHANGELOG URL:  
 https://chromium.googlesource.com/chromium/src/+log/3012edb51ecc3f7266ca385ebdbc5a51094cb09a..f84fefd713b5edd195f0379ca9fb62771b5b6e51

Reviewed-on: https://chromium-review.googlesource.com/914428

@paulirish: Please confirm the bug and help in re-assigning if this is not related to your change. Adding RB-Stable for M-66. Please change if it is not applicable.

Thanks!

Deleted: 838808.mp4 3.4 MB

	838808.mp4 3.4 MB View Download

Hey all,

We've started to see some user reports about this as well.

Listnr:
- https://listnr.corp.google.com/report/85400826085
- https://listnr.corp.google.com/report/85400826085
- https://listnr.corp.google.com/report/85400826085
- https://listnr.corp.google.com/report/85357546653
- https://listnr.corp.google.com/report/85337667951

Community:
- https://productforums.google.com/forum/#!topic/chrome/XRn--fhL-KE

Reddit:
- https://www.reddit.com/r/chrome/comments/8h4l37/help_chrome_copies_image_url_instead_of_image/

Thanks!

Thanks for bringing this up. It's technically facebook's bug. I'll work with them to sort out a fix.

*** Bulk Edit ***
M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

Hi from Facebook – I work on our rich text editor.

In a comment above that line in our internal codebase, we have this note:

    // If HTML is available, treat this data as rich text. This way, we avoid
    // using a pasted image if it is packaged with HTML -- this may occur with
    // pastes from MS Word, for example.  However this is only rich text if
    // there's accompanying text.

(btw that file is open source: https://github.com/facebook/fbjs/blob/v0.8.16/src/datatransfer/DataTransfer.js#L53).

I take this to mean that in some cases Word gives both text/html as well as an image/png on the pasteboard when copying rich text out of a document. I tried to reproduce this but was not able to at a first try with Word + Chrome 65 on Windows 10 (got text/plain + text/html + text/rtf). Not sure if I need another version of Word, another browser, or more complex styles to repro the original issue.

That is to say: we will try a fix by privileging the rich text representation but it's not obvious that there is a simple fix that works for both this Word issue and Chrome 67 together.

Hello,

I don’t see how this is Facebook problem but you know better. The way I tested it was by copy pasting images from 9gag. It works flawlessly on Chrome for Windows but not on OSX. On Windows it pastes the whole image (even tried the same image) and on osx it copies the url.

---
Andrei Neamțu

On 8 May 2018, 05:15 +0300, sophieb… via monorail <monorail+v2.3698126513@chromium.org>, wrote:

@sophie, thanks for the insight. Appreciate you taking a look. Let me know if modern MS Word poses a problem. 

@#c9, to be fair, it's a shared responsibility. I can't say it's 100% the website's issue, but it'a also not 100% the browser's. This is all complicated by the fact that desktop apps like Mail.app and MS Word have handled copy and paste payloads very *interestingly* which has made it difficult for websites and browsers to change their behavior. 

FWIW, here's how clipboardData types break down for copying an image:


| clipboardData copied |  image/png (File) |  text/plain (url) | text/html (html) |
|----------------------|-------------------|-------------------|------------------|
| Mac Chrome <= m66    |         ✓         |        ✓         |                  |
| Mac Chrome >= m67    |         ✓         |        ✓         |          ✓       |
| Non-mac Chrome (all) |         ✓         |                  |          ✓       |
| Safari               |         ✓         |        ✓         |                  |
| Firefox              |         ✓         |                  |          ✓       |
| Edge                 |         ✓         |                  |          ✓       |

*** Bulk Edit ***
M67 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. 

If fix is already merged to M67 and nothing else is pending, pls mark the bug as fixed. Thank you.

As this is regressed in M66 stable and we're very close to M67 stable promotion,  we won't consider this as M67 Stable blocker. Pls let us know ASAP if there is any concern here. Thank you.

sophie, were you able to deploy this change? This will go out to chrome stable very soon.

It has been over a month and 2 weeks since the last comment. Is this going to be fixed anytime soon?

Any news on this?

I experience the issue aswell and I've been through countless threads about it now, trying every solution recommended, but so far none of them has worked. I've seen threads back to 2016 about this problem and apparently still this haven't been solved?

- I've tried Chrome Carnary
- I've tried Incognito
- I've tried clearing cache and cookies
- I've tried resetting Chrome settings
- I've tried using another user in Chrome
- Google Chrome is updated to latest version
- I've checked for malware without finding anything

I'm using Version 67.0.3396.87, on a Macbook Pro with MacOS High Sierra 10.13.5. Problem is still occurring in Chrome Canary Version 69.0.3466.0

recent commenters: are you pasting into facebook messenger or another site/application?

Into facebook messenger is the most common case. If I try copying into word nothing is pasted. This applies to not only facebook images, but I believe it is any image that is "clickable". So it also happens when doing "copy image" on a google image search. Craig, your community manager on reddit, says this issue is on your end. https://www.reddit.com/r/chrome/comments/8h4l37/help_chrome_copies_image_url_instead_of_image/

Into facebook here, either a status/post or messenger. I don't really use any other sites where I need to or can paste an image like that, so wouldn't know if the issue is on other sites too. But I know that the issue doesn't occur in Safari, Firefox or any other browser, so the problem must be Google Chrome and not facebook or anything like that :/

@c20: Craig here - just to clarify, that reddit comment was acknowledging that this was an issue on our radar and confirming that we were investigating (via this bug thread). The comment was published after initial triage (confirming it could be reproduced), but before the discussion in this thread about the complexity of determining root cause / ownership. We'll be more careful in the future with our phrasing choices :)

@c22: So does this mean this isn't going to be fixed? It has been 2 months now.

Seriously, any news on this?

I cannot copy paste images into fb either with google chrome. It will let me copy image adress but then does not display the image which is what I want to do and would rather not have to copy image adress to do so as it jumbles the post and diffuses it. I can copy and paste in firefox. I am not going to try all above steps since this is a known issue that you guys need to work on. I guess I will start using firefox for fb. 
   

Disappointing this is still an open issue.

Workaround:  Open your image in a new tab so it's just the direct image loaded, then "Copy Image", then paste the image.

I like how they said this would be fixed on Chrome 67, and we are already on Chrome 68 with not even an update.

I was able to reproduce on Chrome Canary 70.0.3517.0 on MacOS.

Reproduced on Chrome 68.0.3440.106 and Canary 70.0.3525.0 - copied image from Google image search, pasted into Skype chat, URL was pasted instead of image.

Pasting into Word document correctly pasted the image for me.

@c29: Recreating this way just worked for me as well. This should prove that it ISN'T "just a facebook thing" and is a thing that Chrome needs to fix.

Would be nice if they'd actually communicate anything about this.
They've already missed their target version for the fix.It's getting
really annoying.

paulirish@: Are you still looking into this?

pwnall: I'm not really. 

To recap, we added the `text/html` payload in for copying an image on Mac. That triggered this bug.

On mac that now means the paste payload has 3 image/png, text/html and text/plain.  (On Windows, text/plain isn't present, though I'm not sure why.)
In FB's code the paste makes its way here: https://github.com/facebook/draft-js/blob/0a45fcdf5ebfbb011711643690e06e2b67040928/src/component/handlers/edit/editOnPaste.js#L40-L41  
We want it to get to L45, but it doesn't make it past the `(!data.isRichText())` conditional, which is implemented here: https://github.com/facebook/fbjs/blob/d308fa83c99c93e8e588de3396cf55b31e56b14e/packages/fbjs/src/datatransfer/DataTransfer.js#L53-L59

Possible solutions:
1. Revert this change. 
2. Fix the logic on the FB side to so it handles a (image/png, text/html, text/plain) paste from Chrome as image rather than rich text (while still handling the MS Word case)
3. Don't include text/plain in Chrome mac's image clipboard payload, which should help it avoid the FB conditionals. And this will bring it inline with Windows.
4. Something else

All of these could have unforeseen side-effects. But I'm supportive of any of them.

The spec[1] says the user agent "must" add all possible types to the clipboard, so us providing _more_ types is better in line with the spec. However, as my comment 11 pointed out, there is VAST inconsistency across browsers here, so honoring the spec may not be a high priority. :)


[1] https://www.w3.org/TR/clipboard-apis/#reading-from-clipboard

I've been having this problem on Chrome v69 on MacOS High Sierra. 

When I "Copy Image" from Chrome into PowerPoint 2016, I get the URL instead of the image file.

I'm still experiencing this issue in Chrome Version 69.0.3497.100 on MacOS High Sierra. Have been experiencing it for several months.

Would be nice if this could be added as an option under chrome://flags or something so we can set it to not include text/plain in Chrome mac's image clipboard payload manually.

Yeah... I don't think we will ever be getting a fix for this, based on @c33

Seems like text/plain should not be included, irrespective of Facebook's conditionals.

A URL is not the "text version" of an image... yes a URL is a character sequence, but for that matter so is HTML and SVG. And Chrome already has "Copy Image Address" separate from "Copy Image".

Drop the text/plain payload and make everyone happy?

Simplify the menu items to just be "Copy Image or Address, we will astonish you."

I haven't dug in here, but I vaguely recall that my change https://chromium-review.googlesource.com/565328 was partially reverted due to a subsequent change, and seems like the fix might be related.

huangdarwin@, can you take a look?

Repro'ed on Mac/Chrome 70. Pasting into textEdit or GMail works (pastes the image), but I'm seeing the URL pasted if pasting into Google Image Search or FB Messenger. Drag-and-drop into Google Image Search does indeed yield an image though, but FB Messenger doesn't accept dropping the image. @34 has also mentioned that Powerpoint is affected.

@39, Agreed, the fix seems potentially related, and partially reverted via what seems like a move to system_clipboard...

@33, While in the long term I believe we should be consistent with the spec, enough different applications/webapps seem not to correctly handle this type handling that we may need to provide guidance in our spec to fix this for future cases. I'm not sure that the (2) mentioned would be realistic, just because so many apps/webapps are expecting this less-correct behavior.

Therefore, I'd propose doing the #3 mentioned, keeping our implementations more consistent between OS's. Or under time constraints, #1 would definitely be simpler. Both of these would fix the problem fairly quickly, whereas #2 would work as well, but seems like it would take a while.

After further conversation with pwnall, I now believe that reverting the change (or similar) for now should be the correct solution. 

This potential problem of types added to Chrome (in order to be more inline with the spec) interfering with apps (which expect a less-complete implementation of Chrome) should be handled and considered in design of the future async clipboard. This may be done by including a ordering of type preferences (with the first preference being the "native", not-converted type), and by offering guidance to JS devs to interact via acknowledging this type order.

Also for future reference, via Apple's ClipboardViewer (https://developer.apple.com/library/archive/samplecode/ClipboardViewer/Introduction/Intro.html), Mac/Chrome 70 copies images to clipboard with these additional types over Mac/Safari: public.html and Apple HTML pasteboard type, and Safari has these additional types of Chrome: com.apple.flat-rtfd, NeXT RTFD pasteboard type, com.apple.webarchive, and Apple Web Archive pasteboard type. 

Thanks for investigating this. I support your plan.

Upon further investigation, http://madebyevan.com/clipboard-test/ has shown that the text/plain field in Mac/Safari, which Facebook seems to accept, provides a web URL, while the same field in Chromium provides a data URI. 

We likely need more thought, but while the easiest solution would still be removing the text/html field on OSX, modifying the text/html field to be a URL, and then moving the current data URI to text/uri-list seems viable as well.

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

commit fe5e25087068b481d45d88f5054039a74f60a3e7
Author: Darwin Huang <huangdarwin@chromium.org>
Date: Wed Nov 21 23:00:01 2018

DataTransfer: Remove text/plain payload when copying an image on Mac

Helps fix errors in apps which prefer text/plain content while pasting over img,
even though it is less spec-conformant to provide fewer types than possible. As
noted in the crbug, these apps (ex. Messenger) generally prefer text/plain
content due to compatibility issues with Microsoft Word.

This does also make us more consistent with other platforms (ex. Windows/Linux),
where we don't provide the text/plain field.

Also moved a browser test to a layout test for future ease of testing. The
browser test wasn't able to generate text/plain to reproduce the bug, due to
images only previously producing text/plain output on images with alt text, and
execCommand only operating on iframe DOM objects (not image DOM objects)

Bug:  838808 
Change-Id: I28b2d8d223c2448f47e887323afccae73d6bcf44
Reviewed-on: https://chromium-review.googlesource.com/c/1319032
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Joshua Bell <jsbell@chromium.org>
Commit-Queue: Darwin Huang <huangdarwin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610250}
[modify] https://crrev.com/fe5e25087068b481d45d88f5054039a74f60a3e7/content/renderer/webclipboard_impl_browsertest.cc
[delete] https://crrev.com/405c64c5cdcb9ffa7a870c4e326f0570bdd1c06e/content/test/data/image_copy_types.html
[add] https://crrev.com/fe5e25087068b481d45d88f5054039a74f60a3e7/third_party/WebKit/LayoutTests/editing/pasteboard/clipboard-image-paste-types.html
[modify] https://crrev.com/fe5e25087068b481d45d88f5054039a74f60a3e7/third_party/blink/renderer/core/clipboard/system_clipboard.cc

You labeled this as fixed and it is not in fact fixed. Version 70.0.3538.110 (Official Build) (64-bit)

There hasn't actually been a release since he made the fix. Just be patient and it will make its way into a new build eventually. Thank you for the fix.

"The browser test wasn't able to generate text/plain to reproduce the bug, due to
images only previously producing text/plain output on images with alt text"

Does this mean that because the bug has existed for 7 months now, you no longer consider it a bug?

Where are you guys getting the idea that a URL is a "possible type" of image? That's like saying my home address is a possible type of human being. AFAICT this is just misinterpretation of the spec and was a simple Chrome bug from the start. So strange how much deliberation was needed to see that.

I just find it odd that even the solutions are phrasing the problem as if it's some sort of nuanced dichotomy between supporting Facebook and adhering to the spec, when it appears to be neither. The spec wasn't being adhered to at all, and that was breaking Facebook, unless one makes a radical stretch in their definition of the word "type".

#48: This fix will come out in M72: https://chromiumdash.appspot.com/commit/fe5e25087068b481d45d88f5054039a74f60a3e7 (#49 thank you for bringing this up)

We generally mark bugs as Fixed when we land fixes on master. The Canary channel gets these fixes within a day. It generally takes 6-12 weeks for a fix to make its way to the Stable channel.

#50: The bug was marked Fixed, which means we've landed a CL to address it. When we think something isn't worth fixing or we won't get to it, we use WontFix.

#51: In general, we make decisions around Drag and Drop based on the specification, as well as on maximizing compatibility with existing Web and native applications. These decisions tend involve subtle trade-offs, so and may not seem intuitive to folks who weren't exposed to all the data that we considered. 

In this particular case, the most relevant standards bit is step 7 in Section 6.7.5 of the DnD specification [1], which asks that we extract URLs and add them to the DataTransfer list of types. See https://html.spec.whatwg.org/multipage/dnd.html#drag-and-drop-processing-model

#51: On a separate note, your tone doesn't seem very constructive to me. Please assume that we're doing the best we can to move the Web forward and to build the world's best browser. It's perfectly fine to ask for our thinking behind changes, and we're happy to share that when possible, but please keep the discussion constructive.

https://html.spec.whatwg.org/multipage/dnd.html is fairly large and "The spec wasn't being adhered to at all" isn't specific enough. If you have information you'd like to share, it'd help to point at specific sections. Please cite phrases (copy-paste in quotation marks) if you refer to large sections like 6.7.5.

The general principle behind DataTransfer (drag and drop, copy-paste) is that source applications place as many formats as possible on the clipboard, and consumers pick the best format they can consume. For the image example, when the user drops/pastes an image into a text editor, getting the image URL is more helpful than getting nothing at all.

Sadly, Windows' DataTransfer and its equivalent on other OSes don't have a way to specify the relative fidelity of the formats (like q= in MIME types), and this makes things confusing. I'll give two examples below, to illustrate.

1) When copying / dragging a paragraph of text in a rich text editor, some applications place a rendered bitmap in DataTransfer, in addition to the rich text. This follows the principle above, because the consumers that can't parse the rich text may prefer a rendered bitmap of the formatted text to plain text.

2) When copying / dragging an image in Chrome, we would ideally place the following formats in DataTransfer: the image in its native format, the image converted to a few formats that are popular on the host OS, rich text markup with an image element in it, the image URL, and plain text with the image's "alt" text.  Each of these types would be useful in some specific situation. In reality, we end up placing a subset of these formats, to avoid having images pasted as text in popular applications.

The examples above show that a consumer who can read images and rich text will have a hard time choosing a format from DataTransfer, when both alternatives are available. For this reason, applications try to make educated guesses, a.k.a. heuristics. We (Chrome) do our best to maximize compatibility and spec compliance. Maximizing compatibility depends on the currently popular applications, and the heuristics they follow. Today's best decision may not be great tomorrow.

I hope this helps explain why DataTransfer decisions are not as straightforward as they may seem.

Thank you, pwnall@, for this explanation, and +1 to your comments.

For those curious about images and their place in the clipboard, it has changed quite a bit just in the last year. In the reviews linked above in this bug, here's a chart of which types would be pasted when an image is on the clipboard in Mac/Chrome:
                      Image, Bookmark, HTML
crrev.com/c/565328
Before:                 Y        Y      N
After:                  Y        N      N
crrev.com/c/914428
Before:                 Y        Y      N
After:                  Y        Y      Y
crrev.com/c/1319032
Before (bug filed):     Y        Y      Y
After  (bug fixed):     Y        N      Y

(somewhere between the 565328 and 914428, a change added bookmarks back in, which would eventually cause this bug to be filed)

Version 70.0.3538.110 (Official Build) (64-bit)

When I copy an image directly out of google images and paste into a FB wall post, now it shows up with the textual 'data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAA...' content.

Originally, it would post the image. Then it started posting the URL. I think we've taken a step backwards with whatever else has changed now.

Hey latchkey, thank you for testing and verifying the bug described in this thread. Please read or reread comment #53. For reference, the textual 'data:image/jpeg...' content you see is the text/plain bookmark content that is removed by the fix.

Please let me know if anything continues to feel incorrect or confusing after reading #53.

#58: Confirmed this works again on Version 73.0.3643.0 (Official Build) canary (64-bit). Thanks!

Of course! Thank you for confirming! :)