Enhance 'Paste As Text'

[Garry Yao]

Currently 'Paste As Text' will always open dialog for non-IE, we should also try to access native clipboard in other browsers as well, delivering the most satisfied result based on the maximum capability of all browsers.

[Garry Yao]

There's actually a quite old and classic approach which works fine in Firefox(only for text flavor) through the XPCOM clipboard API, I'm porting it here.

Also, the old routine for detecting IE clipboard accessibility could be further simplified.

Those changes are committed with [4303].

[Garry Yao]

Fred's suggested of trying the textarea hack we had used at #1427 to make this happen when ​user has granted clipboard access, but unfortunately, according to my test, it does't work(the textarea hack is effective only when 'paste' is triggered by a real user action).

[Tim Down]

I've been working on this feature in my own editor recently. My conclusions, which I think will help you:

1. In Firefox 3+ and using a textarea, the paste event is too late: if you turn off designMode and focus the textarea then nothing gets pasted into it.

2. In Firefox 3+ and using a div, the paste event is NOT too late: there's no need to turn off designMode, so just focussing a hidden div in a paste event handler successfully redirects the paste. This is also true in WebKit browsers that support the paste event.

3. In Firefox 2+, the textarea trick works if applied in a keypress event handler for Ctrl-V or Shift-Insert, though in Firefox 2 I have found the caret disappears, never to reappear, once you remove the textarea. You can get round this for Firefox 2 by instead redirecting the focus to a textarea in the parent document rather than the editor iframe, though this causes problems in other browsers.

4. IE is easy because the textarea and div tricks work if you apply them in a beforepaste event handler.

Conclusions:

1. Requiring the user to change any browser settings is bad. This means we can only deal with pastes in code triggered by a real paste action by the user.

2. It's clearly better to use the paste or beforepaste events where they exist because that way you detect all pastes, not just those from the keyboard. As I understand it, IE has had paste and beforepaste since version 5, Firefox has had paste only since version 3 and WebKit has had paste only since sometime (not sure when). Opera has neither.

3. For rich content (as opposed to plain text), the div trick (redirect the focus to a hidden div in the editor iframe) works fine for all major browsers that support the paste event. Therefore, for rich text pastes you should use the paste event where it exists.

4. For plain text content, the textarea trick should be used. Where the beforepaste event exists (IE), the trick should be applied there. Otherwise, the best that can be done is using a keypress event handler and dealing with other pastes some other way (polling the document? Is that how you do it?)

[Tim Down]

I've not fully appreciated how beforepaste and paste events work in IE, so you should continue ignoring my previous comment.

[Garry Yao]

@timdown Your summarization is mostly identical to our discovery, though there were minor divergency here:

4. IE is easy because the textarea and div tricks work if you apply them in a beforepaste event handler.

Move IE selection on 'paste' doesn't work, you'll need to paste manually to the temp div with execCommand('paste'), it's the tricky part.

4. For plain text content, the textarea trick should be used. Where the beforepaste event exists (IE), the trick should be applied there.

Use exactly the same way as above, only use <textarea> in favor of <div>

So let the ​codes talk:

[Garry Yao]

The paste branch has been reviewed and merged into 3.1.x branch with [4772].