Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Paste-HTML example does not allow for pasting images #3812

Open
mdmjg opened this issue Aug 3, 2020 · 7 comments
Open

Paste-HTML example does not allow for pasting images #3812

mdmjg opened this issue Aug 3, 2020 · 7 comments

Comments

@mdmjg
Copy link
Contributor

mdmjg commented Aug 3, 2020

Do you want to request a feature or report a bug?

bug

What's the current behavior?

When trying to paste an img into the paste-html example, nothing gets pasted.

paste_html_gif

  • Information about your OS, browser, Slate version, etc.
    OS: Mac Mojave
    Browser: Chrome
    Slate Version: 0.58.4

What's the expected behavior?

The expected behavior is that the editor should render the image that is being pasted.

@markogresak
Copy link
Contributor

What you are showing on the gif is pasting data.files, not text/html, i.e. you're not pasting HTML. The image pasting logic is handled at https://www.slatejs.org/examples/images

Relevant code:

const { files } = data
if (files && files.length > 0) {
for (const file of files) {
const reader = new FileReader()
const [mime] = file.type.split('/')
if (mime === 'image') {
reader.addEventListener('load', () => {
const url = reader.result
insertImage(editor, url)
})
reader.readAsDataURL(file)
}
}
} else if (isImageUrl(text)) {

@cameracker
Copy link
Collaborator

Hi @mdmjg! I agree it's a little counter intuitive that paste html can't deal with image pasting, however it's mostly because (as @markogresak has pointed out) the paste html example does not support images. It is a bit awkward but I'm hesitant to add image support to the paste example because that example would get a bit unwieldy and duplicative with the image example.

Interested in your thoughts on the duplication here.

@dmitrizzle
Copy link

Pasting images, in some cases, may require a back-end component for complete functionality (i.e. certain web pages will not allow images to be sourced from domains other than the original host). Sounds like out of scope for HTML example but perhaps worth an note/explanation.

@markogresak
Copy link
Contributor

@dmitrizzle not sure if it applies for the scope here. See the images example, it already supports it (see the code in my comment above). When copying the image, it's saved in the clipboard memory and you can read that via FileReader on paste. It's just a binary transfer.

If I understand correctly, what you're describing applies only if you want to store the editor content, including the image. But that's application-specific logic and not a concern of Slate. So it does not make to include it in the example code.

@dmitrizzle
Copy link

dmitrizzle commented Aug 25, 2020

@markogresak I agree, all of this should be out of scope for the HTML example. However, the back-end component I mentioned isn't for storing. It's not really relevant to the point, but thought I'd explain anyways in case anyone is looking for answers here (feel free to remove):

If you ctrl+c content off another website (i.e. you are trying to copy your own blog article and submit it onto another website that uses Slate as an editor), the content is likely not to have images as binary but URLs. What needs to happen from there on, is the image URLs from the clipboard to be either converted to a binary (which won't happen automatically) or have all those image URLs copied on the back-end to the new server and provided as a new URLs. Leaving it as-is may lead to broken images or unintended hosting of images on third-party websites.

@connorjacobsen
Copy link

Taking a screenshot also returns the image as a URL rather than as file data.

@timrobinson33
Copy link

Similarly, if you copy some HTML that includes <img> tags and paste it into slate, the images are removed (which doesn't happen with vanilla contentEditable). This happens on the image demo as well as the HTML example so I presume it's built-in behaviour for slate.

I haven't raised that as a separate issue because although it's different technically, it relates to the same use case, so the discussion here is relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants