Data type of the event paste is different among different browsers

[giorgio]

Catching the event "paste" with the method CKEDITOR.event.on, it doesn't matter what kind of text or html code i'm gonna paste in the editor, in firefox and IE8 i get as data type (evt.data.type) "html", on the contrary, in chrome and Opera i get the type "text".

Please let me know if this is a bug or not.

Regards,

Giorgio

[Piotr Jasiun]

It may happen that for the same data you will get different types depend on browser, because different browser may give different HTML in the paste event and we handle it differently.

But you should not get the same type for every data you paste. I have just checked it on Chrome and I get text type when I paste a text from notepad and html when I paste part of the ​samples page.

[Jakub Ś]

CKEditor recognizes type based on data pasted. I can't see any problems with Text vs HTML just like @pjasun.

Could you perhaps send us sample data that is causing problems for you? Does the same problem happen in default editor or only inside your application?

[giorgio]

Hello,

i tried to grab the type of the data, inside your clipboard plugin, where you set type "dataObj.type = type" , because my understanding is that, CKSource set the type of the data there. I tried to paste any normal text, even from the notepad, and in firefox i get as the type "html" ... always .. i tried also to paste this code in chrome "<iframe width="560" height="315" src="​https://www.youtube.com/embed/sI4KGGqNOAE" frameborder="0" allowfullscreen></iframe>" and i get "text" as the type of data.

Now, maybe i don't understand when those two types should be returned, in the second example should i get "html" as the type of the data or not?

Thanks,

Regards.

[Piotrek Koszuliński]

cc

[Piotrek Koszuliński]

Results from Chrome (latest master):

CKEDITOR.instances.editor1.on( 'paste', function( evt ) { console.log( evt.data.type, evt.data.dataValue ) } );

// Pasted text copied from SublimeText (plain text):
html <p>sdfsdf dsf sdf sdf<br>sdfsdfsdf sdf</p><p>sdf sdf sdf sdf</p>

// Pasted an iframe from code (copying a real iframe maybe tricky):
CKEDITOR.instances.editor1.execCommand( 'paste', '<iframe width="560" height="315" src="​https://www.youtube.com/embed/sI4KGGqNOAE" frameborder="0" allowfullscreen></iframe>');
html <iframe width="560" height="315" src="​https://www.youtube.com/embed/sI4KGGqNOAE" frameborder="0" allowfullscreen></iframe>

On Firefox (latest master):

CKEDITOR.instances.editor1.on( 'paste', function( evt ) { console.log( evt.data.type, evt.data.dataValue ) } );

"html" "<p>sdfsdf dsf sdf sdf<br>sdfsdfsdf sdf</p><p>sdf sdf sdf sdf</p>"

CKEDITOR.instances.editor1.execCommand( 'paste', '<iframe width="560" height="315" src="​https://www.youtube.com/embed/sI4KGGqNOAE" frameborder="0" allowfullscreen></iframe>');
"html" "<iframe width="560" height="315" src="​https://www.youtube.com/embed/sI4KGGqNOAE" frameborder="0" allowfullscreen></iframe>"

Precisely the same result. Why it's always 'html' even though we pasted a plain text in the first case? This is a good question, but there's a good answer to it :). Before CKEditor 4.5.0 we could only guess what's the real type of data. We had HTML taken from the pastebin and based on that we were trying to guess if that could have been plain text or not. However, this is only guessing, so we decided to introduce config.clipboard_defaultContentType which defaults to 'html'. So if we recognise text the type is set to 'html' anyway. This makes the behaviour identical with CKE3, but if anyone believes in the type recognition he/she can change the default type to 'text'.

The behaviour has changed recently in CKEditor 4.5.0 beta where we finally have real knowledge about the data type. If there's no HTML in the clipboard we don't have to guess and we can set the type to 'text'. I've just checked that the previous TC will give first 'text' and then 'html' on 4.5.0 beta on Chrome and... not on Firefox. On Firefox it's still double 'html' for the same reason as before, but perhaps we'll still change that. The problem with Firefox and Safari is that their clipboard APIs are always a surprise, so we decided to back up a little bit. However, I don't think it makes that much sense, so perhaps #13187 will change this.

[Piotrek Koszuliński]

So, I believe that you were testing on 4.5.0 beta. Before 4.5.0 the situation was, according to my knowledge and tests, stable. Now things changed a bit, but they changed on some browsers only. We may still be able to improve the recognition on Firefox and Safari, but we will not be able to achieve anything on IEs which do not support the clipboard API at all. So on IEs we'll have the same situation forever.

I'm closing this ticket as DUP of #13187. #13187 started as an Android's issue, but I think that we are going to generalise the fix so Firefox and Safari are also affected.