When pasting image copied from OS folder (like literally ctrl + c, ctrl +v, not dropping) I get nothing in editor. When debugging I found a place in code (prosemirror-view/src/input.js, doPaste function) which, when pasting, doesn't consider attached images:
function doPaste(view, text, html, e) {
let slice = parseFromClipboard(view, text, html, view.shiftKey, view.state.selection.$from)
if (!slice) return false
if (view.someProp("handlePaste", f => f(view, e, slice))) return true
...
However it lets me add my custom handlePaste prop to a plugin which checks for attached images and can insert them into the doc. slice here is non null, since when copying image in OS folder it, besides attaching a file also adds the name of the file to the clipboardData prop of event, which goes in this function as an text param. Seems to be a workaround.
But when pasting an image copied from Word doc, there is no file name added to the clipboardData, and the workaround I've mentioned above doesn't work. doPaste just returns false since slice is null. In this case even adding custom handlePaste prop doesn't help - it just doesn't get to that line.
Am I doing something wrong or it requires a patch? Thanks.
Yes, this definitely will work for me! Thanks a lot. Sorry for dumb question, but how it usually works - when this patch will be available in ProseMirror?
Hi, we just updated our prosemirror dependencies, and our own code for detecting image pasting broke.
This patch remove the return false statement in doPaste(), which means it always return true.
In turns, that means that in editHandlers.paste = (view, e) => {}, the branch capturePaste(view, e) is never called.
That means that base64-encoded images are never inserted with a paste.
We were relying on the presence of data:image in the slice string to detect copied image, but now the slice is always null. There’s probably another way to detect a pasted image, because @korochinsky is doing it ( an attribute in event.clipboardData maybe ? ), but anyway that looks like a regression to me.
Yes that would indeed trigger the capturePaste() function.
However one would now need to be cautious in the writing of the handlePaste() implementation because it’s now called twice : once by doPaste() and once by capturePaste(), with the first one having a null slice and the second one with a non-null slice.
I made a comment on the github patch, but I’m not sure if this is the right approach to get you notified, so in doubt I double-post here. Tell me which method you’d prefer.
The patch introduce a bug by swapping parameters in the call to doPaste() ( see my github comment for precise pinpoint )
Hello. Seem’s like multiple call of handlePaste() happens again.
It happens for non ‘text/plain’ content from clipboard.
Why did you decide to revert your changes? And may be you have any ideas how to filter handling useless second call of handlePaste()?
Also, we cannot access to pasted image due to slice is empty, Because slice takes only copied text. Is it works properly or in general slice has to get any other clipboard content also?
And event.clipboardData.files are empty also…
But we can access to image blob via navigator.clipboard.read().
