1. Open attached sample. 2. Select some text in the editable element ("bar"). 3. Use "Copy" option from the content balloon. 4. Move selection somewhere else in the editable element (put caret after "Foo"). 5. Try to paste. Expected result: "xxx" will be paste (see the code). Actual result: No paste option is available. It works fine on the desktop browsers (tested with Safari, Chrome and Firefox). Does not work on iOS 8.3 with mobile Safari 8 (AppleWebKit/600.1.4). I tried to set all data types Safari@iOS set by default ("apple web archive pasteboard type", "public.html", "public.png", "public.tiff", "public.jpeg", "com.compuserve.gif", "text/uri-list", "text/plain", "com.apple.rtfd", "public.rtf") but it does not solve the problem.
The sample code: <html> <head> <title>Custom copy cut</title> <meta charset="utf-8"> </head> <body> <div contenteditable="true" cols="80" id="editor" rows="10">Foo bar bom</div> <script> editor.addEventListener( 'copy', copyCutListener ); editor.addEventListener( 'cut', copyCutListener ); function copyCutListener( evt ) { evt.clipboardData.setData( 'text/html', 'xxx' ); evt.clipboardData.setData( 'text/plain', 'xxx' ); evt.preventDefault(); } </script> </body> </html>
Because of that bug is is not possible to implement custom copy and paste in the CKEditor, http://dev.ckeditor.com/ticket/13188.
It's a pity that it doesn't work in Safari@iOS, because it works fine in the Safari@MacOS. The ability to call setData() on copy/cut is crucial for a good copy&paste support in WYSIWYG editors. Unfortunately Webkit and Blink put the whole spectrum of inline styles into the clipboard and most of the developers do not want all that mess in their databases. Therefore on browsers like Firefox, Chrome and Safari on MacOS CKEditor sets clipboard data to exactly the content that was selected and uses that content on paste. On Chrome it also sets additional clipboard item to identify the pasted data as coming from the same (or different) editor. This is extremely useful because it allow to handle data coming from an editor differently than from the outside.
*** Bug 143775 has been marked as a duplicate of this bug. ***
I would like to ask someone to take a look at this, since Mobile Safari is now the only current browser which doesn't properly support this API. If it's a simple bug, it's probably not hard to fix. If things are this way for a reason, it'd be useful for us to know that reason.
This should be fixed as of iOS 11.4, with our Clipboard API cleanup work. I tested on iOS 12, and the problem does not reproduce.
Note: there's a variant of this bug where "Paste" does not appear in the callout bar if the only types written to the pasteboard are custom types, but the test case here avoids the issue by sticking to "text/html" and "text/plain" (for more detail, this is <https://bugs.webkit.org/show_bug.cgi?id=184271>).