Container task for pasting images from clipboard from Safari or Firefox.
Safari Bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=75891
Firefox Bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=891247
Container task for pasting images from clipboard from Safari or Firefox.
Safari Bugzilla:
https://bugs.webkit.org/show_bug.cgi?id=75891
Firefox Bugzilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=891247
This has never worked, and still wasn't practical to implement when I checked last year (T5411#64865).
http://stackoverflow.com/questions/2176861/javascript-get-clipboard-data-on-paste-event-cross-browser/6804718#6804718 is about as general a solution I could find.
As I recall, the problem isn't getting the event (that's relatively straightforward), it's reading image data out of it. At least as of a year ago, Safari and Firefox did not let you read image data from a paste.
At that time, it was technically possible to implement support in Firefox by refocusing a hidden <div /> with contentEditable, then examining the pasted data and copying it back to whatever the original target was, but the complexity of doing that is unreasonably high. This is what Imgur did at the time, but they don't have to worry about handling normal text.
I can look at this again, but I suspect nothing has changed. In particular, copy/paste still doesn't work on Imgur in Safari. It works fine in Chrome, and it works in Firefox (but presumably because they still use the high-complexity contentEditable stuff).
Not important to me, just wanted to fill in the details for when it does come up again.
From the Firefox bug and this linked one:
https://bugzilla.mozilla.org/show_bug.cgi?id=906420
...it looks like this stuff is being actively addressed in Firefox (updates to tickets within the last few days). Not clear if that actually means it will be available in a release any time soon, but it does makes a Firefox-only contentEditable hack less attractive because it would presumably be short-lived.
This doesn't appear to even to be possible in Firefox. Here's a simple example:
<!doctype html> <html> <head> <script type="text/javascript"> var onpaste = function() { document.getElementById('pasteNode').focus(); }; window.addEventListener('paste', onpaste, true); </script> <style type="text/css"> body { background: grey; } textarea { width: 400px; height: 200px; } div { width: 400px; height: 200px; background: white; } </style> </head> <body> <textarea id="typeNode"></textarea> <div contenteditable="true" id="pasteNode"></div> </body> </html>
Paste text into the <textarea /> (the top box). If things work, an image will appear on the bottom box.
In Safari, the focus() fires before the paste, so the content ends up in the <div />. This would potentially let us inspect the content and extract any pasted images. This appears viable in Safari, except that it doesn't seem possible to extract the image data (?), e.g. see:
https://bugs.webkit.org/show_bug.cgi?id=49141
(Note also that Gmail does not appear to support pasting images in Safari: when you paste an image, it just removes it. I suspect there is no workaround and that no site supports pasting images in Safari.)
In Firefox, the paste fires before the focus() so the content doesn't go into the contentEditable div, so we can't get it.
Gmail (and presumably other applications) have the user edit text in a contentEditable div, not a <textarea />.
Imgur sues a similar strategy to the above, but it starts without an editable element focused. In this situation, Firefox has different behavior: the refocus works and the content ends up in the <div />.
Upshot:
I'm observing same issue in current ChromeOS 55.0.2858.0 dev branch.
At the same time image paste works in Telegram web client (seems that they use contentEditable div instead of textarea)
Do you know whether it's a chrome os bug or google deprecated DataTransfer.items in new chrome's?
I can't reproduce this in Chrome (OS X, Version 53.0.2785.116 (64-bit)) so it may be a behavioral change in Chrome.
Linux Chrome dev channel 55.0.2859.0 (64-bit) have no issues with image paste.
Seems that it is ChromeOS specific issue.