pastePlain, imagePaste, & pasteAllowedStyleProps ignored when pasted from another Froala Editor

[JaxonWright]

Expected behavior.

These settings should be followed regardless of where the copied text came from

Actual behavior.

If text is copied from a different Froala editor, these options are simply ignored and you now have formatting pasted in that you do not want. This is true even across webpages as long as it is in the same domain.

That means if your website has a more fully-featured editor somewhere and a more restricted one somewhere else, the user can paste stuff that shouldn't be allowed from the first one to that one.

Steps to reproduce the problem.

1. copy rich text within one editor
2. paste it into another editor that does not allow that styling
3. Observe that the styling was preserved!

Here is an example JSFiddle: https://jsfiddle.net/4j0ufLdb/17/

Notice that formatting is stripped when pasting the text at the bottom of the page into either editor, but it is not when pasting the rich text between editor 1 and 2.

Editor version.

v3.1.0

OS.

Windows 10

Browser.

Chrome, Firefox, probably more

[Warwizza]

I probably have the same issue. When pasting in a single paragraph from for example the Lorem Ipsum website the pastePlain option removes the styling of the text, but when pasting in 2 or more paraghraps with styling, the styling is preserved.

Steps to reproduce:

1. Open the JSFiddle from above (https://jsfiddle.net/4j0ufLdb/17/)
2. Open the Lorem Ipsum website (https://www.lipsum.com/)
3. Copy the first block including the title. The styling is removed from the copied text.
4. Do the same thing only with 2 or more paragrahps, but now the styling is preserved.

[JaxonWright]

It appears that this happens because there are 2 items saved in localStorage when copying text within Froala, fr-copied-html and fr-copied-text. It seems like if the clipboard contents matches those, it assumes it didn't come from another Froala field and is valid entry for the current one.

Copying and then removing those localStorage values makes it behave as expected. This can be done within the window.copy event for the editor as so:

events: {
    'window.copy': function () {
      localStorage.removeItem("fr-copied-html");
      localStorage.removeItem("fr-copied-text");
    })
  }

This is not ideal, but it at least gets around the issue for now

[yellow1912]

Just a warning but you fix will cause another unexpected issue: https://github.com/froala/wysiwyg-editor/issues/4250

Froala team needs to step up their game and fix this long running bug.

[gkilwein]

This is a big problem for our users - it copies over a ton of unwanted style tags that cause all sorts of user headaches.

[jordankittle]

Pasting from Google docs ignores all my pasteAllowedStyleProps. It is really frustrating.

[dev-mohanraj]

I'm facing the same issue, copy paste is like a mental model which is a burden to copy an item from google docs or inside the editor

[DavidEichmann]

To bring some clarity to this issue, this is how I see things for my use case:

Froala's API allows me to control html clean-up "on paste" via various options and events, but really what I want is for the editor to always contain clean html. Hence, html copied from arbitrary sources must be cleaned on paste, but html copied from within the froala editor is safe to paste unaltered because it is already clean. This was probably the motivation behind Froala's behavior:

• Froala uses localstorage to try and identify if a copy+paste happed within froala. In that case Froala avoids cleaning the pasted html so as to maintain existing formatting.

This behaviour seems reasonable at first glance, but I expect cleaning HTML (for the most part) to be idempotent, clean(clean(html)) === clean(html), which means that Froala's behaviour is just unnecessary complexity. The workaround forces Froala to clean all pasted text. It seems that since this issue was created Forala's cleaning function has become closer to idempotent and so the workaround is less of an issue.

In addition, Froala's behavior is buggy in another way (#4693) that encourages using this workaround!