Opened 16 years ago

Closed 14 years ago

#1427 closed New Feature (fixed)

Autodetect clipboard contents on Paste

Reported by: Alfonso Martínez de Lizarrondo Owned by: Garry Yao
Priority: Normal Milestone: CKEditor 3.1
Component: General Version:
Keywords: Confirmed Cc:

Description (last modified by Alfonso Martínez de Lizarrondo)

I've commented previously on this idea, but I can't find it so I'll leave this open so it doesn't get lost:

The access to the clipboard contents was easy in IE<7, but in IE7 by default the user will be faced with two warnings (#89), and in the rest of the browsers it's even harder.

The idea would be to allow the paste event to take place and compare the snapshot of the source just before and after it happens, the difference is the clipboard content that can be cleaned from Word rubbish, do a full-format clean up or even convert it to plain text. Then it's a matter of revert back to the previous undo state and insert the cleaned up code.

This would also allow more easily to use designMode to highlight the source view.

This page has an implementation of a JS diff algorithm that could be a base for this code: http://en.wikipedia.org/wiki/User:Cacycle/diff it includes references to other implementations that could be worth checking if this doesn't work just as expected.

This same algorithm could be used to mark insertions or deletions in the content.

Attachments (1)

1427.patch (15.7 KB) - added by Garry Yao 15 years ago.

Download all attachments as: .zip

Change History (20)

comment:1 Changed 16 years ago by Alfonso Martínez de Lizarrondo

Description: modified (diff)
Summary: Autodected clipboard contents on PasteAutodetect clipboard contents on Paste

comment:2 Changed 16 years ago by Frederico Caldeira Knabben

Keywords: Discussion added
Milestone: FCKeditor 3.0

The theory is interesting. It is still difficult to catch the "before" and "after" pasting event in all browsers. It's also difficult to achieve it without making the content "flash". But it worths giving it a try.

comment:3 Changed 15 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 3.0CKEditor 3.x

comment:4 Changed 15 years ago by Garry Yao

Interesting approach Alfoonsoml, actually TinyMCE has already implement this feature, with a pretty clever way:

			// This function grabs the contents from the clipboard by adding a
			// hidden div and placing the caret inside it and after the browser paste
			// is done it grabs that contents and processes that
			function grabContent(e) {
                           ...

comment:5 Changed 15 years ago by Alfonso Martínez de Lizarrondo

Recently I worked on this idea, and using a "dumb" diff between the original and the after-paste contents doesn't work.

As the content is in design mode, it must work with dom nodes, I mean: the original source might start as <img src="pic1.jpg"> and the new content is <img src="blue.jpg"> then the algorithm must say that the difference isn't just "pic1" vs "blue", all the <img> must be replaced (as it will be added with .insertHTML)

This can become very complex, so I throw away the simple idea, then I checked that it's possible to "empty" the document before pasting and then you get exactly the clipboards contents. The drawback is the flashing on the screen.

So I also ended up using a div and it seems to work (just for Firefox 3), it isn't a very complex code, it just needs to be tuned up for each browser.

comment:6 Changed 15 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 3.xCKEditor 3.1

The <div> trick is interesting, and actually it could be the way for us to go.

We should have advanced support for clipboard operations with the 3.1. I'm targeting this one there for investigation.

Changed 15 years ago by Garry Yao

Attachment: 1427.patch added

comment:7 Changed 15 years ago by Garry Yao

Keywords: Confirmed Review? added; Discussion removed
Owner: set to Garry Yao
Status: newassigned

It's decided that this will be one of the important features we must have in the new paste system(#4379) for 3.1.

I'm porting the TinyMCE approach here with this patch, and doubting that it would be the only reliable cross-browser way to make this feature happen.

@alfonsoml: It would be great if you could also attach the approach you proposed here for a dicussion.

comment:8 Changed 15 years ago by Garry Yao

Keywords: Review? removed

As discussed with Fred, this feature should not using the way of patch on trunk, so instead I've checked in the proposed changes into the separate 'pasting' branch with [4206].

comment:9 in reply to:  7 Changed 15 years ago by Alfonso Martínez de Lizarrondo

Replying to garry.yao:

@alfonsoml: It would be great if you could also attach the approach you proposed here for a dicussion.

As I said I focused just on Firefox, the basic idea is just the same that the one that you have coded there, selecting the contents of a div (of course, empty) and then reading the new content.

After that, just a custom way to process the data that it's much clearer with the new architecture.

comment:10 Changed 15 years ago by Garry Yao

Luckily I've managed to find a trick to enable grabbing plain text format also, with this we could have two modes( text/plain and text/html ) been properly handled when using Ctrl-V without open any dialog or suffer from security warnings.
These changes were checked in at the pasting branch with [4217].

comment:11 Changed 15 years ago by Alfonso Martínez de Lizarrondo

This is just my opinion, but I think that the paste as text as we currently know it will disappear once the automatic detection of the clipboard is added and people uses it.

The reasoning is if they really wanted just plain text the would be using a textarea not a wysiswyg, but the problem was that allowing normal paste it did include things that they didn't wanted, so the lesser evil for them was to paste only the text removing all formating and structure, but if the new system is designed so they can easily hook their cleaning function they will be much more happy.

For example, in the mediawiki integration it's forced the plain text paste and it's a PITA to copy and paste anything, besides the dialog that now will be removed, any previous formatting of that text is lost, so the user has to waste time reformatting it again, even if he was just copying some content from the same article.

Using the paste events now it will be possible to process the incoming html and remove styling, unsupported tags, undesired attributes... but leave the links there, retain the lists, headings... paste something clean but not raw text.

So extending the detection system to grab just the raw text isn't too useful IMHO

comment:12 Changed 15 years ago by Garry Yao

@alfonsoml I see the rational behind this thought, while somtimes raw format != html format + cleanup, just for an example:
A bulletlist in clipboard from MS-Word variants from text to html:

//Expected text presentation
&bull; item1;
&bull; item2;

compare with

//Expected HTML presentation 
<ul style="list-style-type: disc">
 <li>item1</li>
 <li>item</li>
</ul>

And the above result for text even various for platforms, so if we could have the browser handling the text flavor for us, why we need to in contrast implement it by ourself.

comment:13 in reply to:  11 Changed 15 years ago by Frederico Caldeira Knabben

Replying to alfonsoml: Let's say that the Paste as Plain Text feature is simple an additional feature. Is up to the developer to use it or not. It's a simple and fast solution for the problem, while we'll still have the advanced thing you have described for those who are willing to spend time on writing their custom pasting filters.

comment:14 Changed 15 years ago by Tim Down

Regarding the paste as plain text feature using a textarea that is focussed in the paste event handler, are you sure this works? I tried exactly this approach in a projct I'm working on and found that in Firefox 3.5 at least the textarea was not populated with pasted content and just remained empty, possibly due to turning off designMode. I worked around this by instead using a hidden div (as you do in your normal HTML paste mode), leaving designMode on and retrieving the text content from the div by selecting its contents and calling toString on the selection object.

comment:15 Changed 15 years ago by Garry Yao

@timdown

It WFM in FF3.5 by turning off design mode before giving focus to textarea.

retrieving the text content from the div by selecting its contents and calling toString on the selection object.

Thanks for the sharing your experience, while the approach you're using is not fit for our needs, as I denote before, raw format != html + getText, instead it must be something identical to 'text/plain' data flavor of the system's clipboard.

comment:16 Changed 15 years ago by Tim Down

@garry.yao

I'm not quiet sure what you mean by "raw format != html + getText, instead it must be something identical to 'text/plain' data flavor of the system's clipboard." - what is getText? In any case, I think you're right - I've spotted a problem with leading space disappearing with my div solution.

Is there anywhere I can get a build to test?

comment:17 Changed 15 years ago by Garry Yao

@timdown We're at an exploration stage for this feature which means it's not available in the build, it will be one of our major features for the 3.1 release, please stay tuned.
Anyway, please use our forums for discussions and community support.

comment:18 Changed 15 years ago by Garry Yao

As discussed with Fred, we should prompt user a confirmation to let the user decide whether performing any cleanup when pasting from MS-Word, which has been checked in with [4265].

comment:19 Changed 14 years ago by Garry Yao

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy