I think I am beginning to see the problem with cut and paste. It pretty much works only in IE, and even that is possibly wrong, because it is a security problem. Can you imagine if some rogue script could sit in the background and make periodic snapshots of your clipboard...
What would make complete sense to me, is if the browser has limited access to clipboard access only when it is part of a paste event. This would be analogous to how file access works: Generally a browser cannot access just any file on the disk, but one that was explicitly selected by the user can be accessed. In the same way, an explicit user-initiated paste event should make the clipboard available. But I may be completely wrong in this assessment of mine, and this is not how it works in any case. So...
The way to work around it is to create an invisible area, usually off-screen, and redirect paste events into that area, then collect the content of the off-screen area afterwards, sanitise it, and insert it into the editor. This is what the Aloha paste plugin does. It collects the pasted content, and calls the insertHTML command to insert it into the editor. This in turn fires the contenthandlers for insertHtml, which we have been advised to configure such that the word handler is called.
But we don't use the Aloha paste plugin in github-book. I turned it on and it seems to work fine.
So, in theory we could enable the paste plugin, then configure handlers for insertHtml, and that should be that?
I'm curious if anyone might know the pitfalls in that.
regards,
Izak