[Chrome] Pasting copied images into chrome from paint or "printscreen" should be supported

[Jonathan]

Pasting images into CKEditor should support pasting copied images from MS Paint or from "PrintScreen" into Chrome as it does in IE11 and Firefox.

Comment #7 here seems to indicate that it is not possible for this to work for Blink browsers. ​http://dev.ckeditor.com/ticket/11526#comment:7

However, this particular functionality is supported by Chrome.

I was able to verify this by using the following code in the paste event on a simple contenteditable div:

var items = (event.clipboardData || event.originalEvent.clipboardData).items;
var blob = items[0].getAsFile();
var reader = new FileReader();
reader.onload = Function.createDelegate(this, function (event)
{
    var image = document.createElement("img");
    image.src = event.target.result;
    this.Container.appendChild(image);
}); 
reader.readAsDataURL(blob);

The gotcha is that clipboardData.items is cleared in Chrome at the end of the execution of the browser’s paste event. If you try to access the items collection outside of the paste event (after a setTimeout is called), the items collection has been cleared and is no longer accessible. In my testing items[0].getAsFile() needs to be called before the paste handler execution completes.

[Piotr Jasiun]

Changes done, in ​t/12961.

I wanted to report this on the Chromium bug tracker, but apparently it's not a bug, it's feature. According to ​this discussion image copied from MS Paint or from "PrintScreen" is not, in fact, a real file, so it does not land in the list of files. It makes some sense.

[Piotrek Koszuliński]

The branch wasn't pushed.

[Piotr Jasiun]

My bad. I called the branch t/12691. Fixed.

[Piotrek Koszuliński]

What if there are many items? Items are kept in an array, so it means that someone was expecting that it may happen. E.g. some program may allow to copy multiple "graphics items", just like it's possible in a file browser.

As far as I can see this is implemented by a private method which is then used while caching data. So if such situation will happen in the future, we will be able to change this without touching private API.

What worries me though is that someone may want to access items specifically or only files. What we do (merging files with items which are files) seems to be useful on most occasions, but I wonder if it won't create some problems. I think that it should be ok, because as a last resort one can access the native clipboard directly and get only what she/he wants. WDYT?

[Piotr Jasiun]

I was also thinking about these limitation, but then I realized what is DataTransfer facade and why it is introduced. It is created to hide implementation difference in browsers and provide common, simple API, similar to the old clipboard API (so getData and files, no items, which are new, not yet native supported API). Most browsers put the clipboard image in the files so this is how facade should behave. Also if any program will give multiple image items we will not be able to guess witch one is correct anyway. For example it could be Photoshop layers and pasting all of then might not be a expected behavior.

[Piotrek Koszuliński]

I force pushed ​branch:t/12961.

I've got one red in ​http://tests.ckeditor.dev:1030/tests/plugins/filetools/fileloader on IE11.

[Piotrek Koszuliński]

Besides this red test and #13029 everything works fine.

[Piotr Jasiun]

I fixed the red test (actually it was not related race condition) and #13029 is unrelated, occur on major too.

I also find the issue with the file in both files and items (this is what Chrome do), added tests and fixed issue.

Changes in ​t/12961.

[Piotrek Koszuliński]

I've still have one red (access denied) on IE11 on ​http://tests.ckeditor.dev:1030/tests/plugins/filetools/fileloader#tests%2Fplugins%2Ffiletools%2Ffileloader%20-%20test%20cancel%20fileUploadRequest

[Piotr Jasiun]

Check it now. It still not related to this ticket and I am still not able to reproduce this bug, but this fix should help.

[Piotrek Koszuliński]

Fixed on major with ​git:910de7a.

[Jonathan]

Thanks for fixing this!