Fix bug #329: Copy-pasting does not work on IE11

[YoranBrondsema]

The Internet Explorers (including Edge) have a non-standard way of interacting with the Clipboard API (see http://caniuse.com/#feat=clipboard). In short, they expose a global window.clipboardData object instead of the per-event event.clipboardData object on the other browsers.

[mixonic]

Cool @YoranBrondsema! Can you put the clipboard set/get data into a utility file that wraps the browser hack and describes it (as you did in the PR message)?

And since you wrote the test helpers to properly fallback for non-standard API, I don't think you should need to skip the assertions in IE? We should definitely test the paste behavior in IE, or this could regress again and we would still miss it.

[YoranBrondsema]

Cool @YoranBrondsema! Can you put the clipboard set/get data into a utility file that wraps the browser hack and describes it (as you did in the PR message)?

Sure, just added that in the latest commit.

And since you wrote the test helpers to properly fallback for non-standard API, I don't think you should need to skip the assertions in IE? We should definitely test the paste behavior in IE, or this could regress again and we would still miss it.

The thing is that the behavior of pasting is not entirely the same for Internet Explorer browsers now. If you look closely you see that I didn't skip all assertions on IE; I just modified the tests according to the altered behavior (the test suite tests/acceptance/editor-copy-paste-test.js now succeeds on IE11).

The reason for the difference is that IEs don't make a difference between text/plain and text/html when fetching the clipboard data. In order to avoid having HTML code pasted as plain-text, I parse all pasted data as HTML. But this means that text content such as abc\ndef (with the newline) will not be properly parsed as text. On non-IE this is parsed using the TextParser so will turn into <p>abc</p><p>def</p> but because of this limitation on IE it will be parsed by the HTMLParser (because it's always interpreted as HTML) resulting in <p>abc\ndef</p>. The same holds for lists.

I chose to go this route as I didn't think having a regex-style "HTML-detector" that would detect whether to use TextParser or HTMLParser would be robust enough. But I'd be happy to know if there's a better solution to this!

[bantic]

@YoranBrondsema This is great, thanks. Truly odd that IE only maintains a "Text" property for the clipboard data.

I'm going to merge this in and add two separate issues for follow up:

• that newlines in textNodes are preserved by the HTML Parser (we should be sanitizing that whitespace)
• allowing pasting of plain-text in IE

Perhaps in the future we can do something trickier, like retargeting the pasted content into a hidden textarea and reading out whatever (HTML or text) was pasted into it.

[YoranBrondsema]

Perhaps in the future we can do something trickier, like retargeting the pasted content into a hidden textarea and reading out whatever (HTML or text) was pasted into it.

I think this is the way to go but I wanted to fix the biggest issues quickly, that's why I didn't end up doing this. Thanks for creating the follow-up issues!