Cannot paste HTML in IE

[robbertbrak]

When pasting HTML in IE, only plain text is preserved.

To reproduce:

• Copy some HTML with formatting (such as this line) to the clipboard.
• Go to http://facebook.github.io/draft-js/ in IE.
• Paste the clipboard contents into the editor.
• Expected result: the formatting is preserved.
• Actual result: The formatting is lost.

IE does not expose text/html on the clipboardData, so this may be difficult to fix. There are working workarounds, though, such as the one described on http://stackoverflow.com/a/6804718/815176. This workaround involves:

• temporarily stashing the current editor contents
• allowing the browser to natively paste into the contenteditable area
• reading the contents of the contenteditable area

Would such a workaround be considered for inclusion in the framework?

[flarnie]

Thanks for reporting this @robbertbrak - we have talked about improving the copy/paste feature and this seems potentially related. I'll post here when I get an update about that - @mitermayer might have a more detailed response though.

[intentionally-left-nil]

@flarnie: I just implemented a fix for this in our fork of draft.
textioHQ@86b8a41

It's something I'd like to consider getting into the core part of draft. The high level idea is to move focus during the paste event to a temporary div, and grabbing the HTML from there.

I had to work around a few bugs to implement this:
facebook/react#8909
facebook/fbjs#190

I also ran into some IE/Edge specific quirks: The pasteTrap div has to be present and not hidden or display:none at the time of focus. The event has to be either captured, or bubbling with eventTarget no higher than the contenteditable div.

Otherwise it seems to work pretty well!

[intentionally-left-nil]

The reason I used a temporary div is to avoid any flashing behavior where the DOM redraws without the correct content

[robbertbrak]

@AnilRedshift great to hear that other people are working on this as well! My own solution, similar to yours, is implemented in robbertbrak@3aee43f.

I ran in the same issues that you mentioned. In addition, and just for reference, I noticed that Draft adds the following CSS to the contenteditable div: -webkit-user-modify: read-write-plaintext-only (see https://github.com/facebook/draft-js/blob/master/src/component/base/DraftEditor.css#L17). I'm not sure why that attribute is necessary for Draft, but if it's there, it prevents Edge from pasting HTML into the element.

[intentionally-left-nil]

@robbertbrak: Yes the pattern is pretty similar. You are able to get away with creating the clone div in the context of the paste handler and having it work? My testing was unable to get that to happen.

Also doesNotSupportHTMLFromClipboard should include safari < 10.

Lastly, does your fix work for Edge? I just want to make sure I'm not crazy. I was unable to get this working on Edge without changing the paste handler to not be delegated from the root #document

Thanks!

[intentionally-left-nil]

Perhaps we can start a slack channel and hash out a PR, and also for anyone else who has looked into this space.

There's a similar bug that we've found which is that if you enable the group policy to disable programmatic clipboard access, then the vanilla draft-js no longer can paste correctly.

This approach has the potential to fix that as well.

[robbertbrak]

@AnilRedshift My fix does work for Edge, as you can ascertain for yourself.

As for Safari: we did some experiments on Safari 9 and 10 and found that its behaviour is slightly different from IE/Edge, although the same technique can be used to solve its problems. In Safari, it turns out that HTML on the clipboard is supported, it's just not always present:

• When copying from Chrome or Office (MS or Open) into Safari, there is HTML on the clipboard
• When copying from Firefox, there is also HTML on the clipboard, but it contains less information
• When copying from Safari, there is no HTML on the clipboard.

In light of these inconsistencies, the best results are produced when using the technique I used in my commit. So yeah, doesNotSupportHTMLFromClipboard should also include Safari (including version 10, according to the results we found).

[JeanCarriere]

Up. Is there a solution to this problem?

[ironosity]

@robbertbrak or @AnilRedshift have you tried submitting a PR to get this fixed? This is an annoying issue and I would rather no fork draft-js if possible...

[robbertbrak]

@ironosity I haven't, but you are of course welcome to submit a PR of your own, based on our forks!

[colinjeanne]

@ironosity I am slowly moving the textioHQ fork forward so that I can make PRs for features like this one. Our implementation of copy/paste, though, may need a bit of work to become generic enough for Draft itself since it relies on a fair number of tricks and depends on some specific CSS.

[flarnie]

I'm going to try and look into this. Thanks to those who have posted - please let me know if someone has a PR ready for this, otherwise will be debugging it in my spare time.

[intentionally-left-nil]

@flarnie I'm happy to help out, the biggest concern I had was the fact that I was adding a new DOM element (the paste trap) to the draft editor.

Particular care needs to be taken with both IE11 and Edge to work around their various issues. It's been awhile since I looked at this and perhaps there's an easier way than my above PR.

Let me know if you need my contact info.

[robbertbrak]

@flarnie Great to see this issue being activated again. Unfortunately I don't have a PR ready, as we're somewhat behind on our fork. However, you might get some inspiration from looking at our implementation of editOnPaste: https://github.com/robbertbrak/draft-js/blob/0.9-stable-itrp/src/component/handlers/edit/editOnPaste.js.

We have used this implementation successfully in production for quite some time now. It works well on the three browsers that we consider problematic for pasting HTML: IE11, Edge and Safari.

[colinjeanne]

@flarnie, I am also very happy to help. The paste mechanism we have had in place that @AnilRedshift mentioned has been working well for us but it is a significant departure from what Draft currently does.