Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#10328 closed Bug (fixed)

Inconsistency in paste as plain text

Reported by: Perttu Myry Owned by:
Priority: Normal Milestone:
Component: Core : Pasting Version: 4.0 Beta
Keywords: Webkit Cc:

Description (last modified by Jakub Ś)

Pasting seems to work bit differently when using ctrl + v and forcePasteAsPlainText option in comparison to using paste as plain text plugin when enter mode is set to div. Via paste as plain text plugin I got correct looking HTML with divs and br elements, but when pasting via ctrl + v I got just br elements as line breaks.

Here is the plain text content that I copy-pasted.

#1 first

#2 second
#3 third

And here's how the source looked after pasting using ctrl + v.

<div>
<br />
#1 first<br />
#2 second<br />
#3 third<br />
</div>

I also checked out the event in editor.on('paste') handler and event.data.dataValue looked like this when pasting using ctrl + v.

<br>#1 first<br>#2 second<br>#3 third<br>

Whereas the event.data.dataValue looked like this when using paste as plain text plugin.

<div>#1 first</div><div>#2 second<br>#3 third</div>

Is this a bug or do these two different "paste as plain text" methods work differently by definition?


Edit:
Problem can be reproduced in divarea sample in Webkit browsers from CKEditor 4.0 beta. Editor must have following settings:

CKEDITOR.replace( 'editor1', {
	extraPlugins: 'divarea',
	enterMode : CKEDITOR.ENTER_DIV,
	forcePasteAsPlainText : true				
});

Pasting with Ctrl+V and with dialog produces different results.

Attachments (3)

divs.txt (34 bytes) - added by Jakub Ś 6 years ago.
build-config.js (1.5 KB) - added by Perttu Myry 6 years ago.
build-config.2.js (1.6 KB) - added by Perttu Myry 5 years ago.

Download all attachments as: .zip

Change History (13)

comment:1 Changed 6 years ago by Jakub Ś

NOTE: continuation of #10294.

comment:2 Changed 6 years ago by Jakub Ś

Status: newpending
Version: 4.1

Hi,

If I understand correctly you have below configuration in editor used (force paste as plain text and enter mode set to div):

var editor = CKEDITOR.replace( 'editor1', {
	enterMode : CKEDITOR.ENTER_DIV,
	forcePasteAsPlainText : true
} );	

Now you clear editor contents (New Page command) and then paste NOTEPAD text with CTRL+V or with paste as plain text dialog and you see differences.

I have checked this and final result in editor was always the same. After pasting and switching to source I was able only to see

<div>
<div>#1 first</div>

<div>#2 second<br />
#3 third</div>
</div>

@c2456 what have I missed and what are exact steps to reproduce this - to see differences in editor?

comment:3 Changed 6 years ago by Perttu Myry

With default setup I could also reproduce proper results so I started to browse through what plugins we have in our setup. It turned out that ctrl + v pasted data is correct when using iframe editing area, but when using div editing area plugin I was able to reproduce this issue.

comment:4 Changed 6 years ago by Jakub Ś

@c2456 could you tell me in which browser are you getting this issue? Could you also provide your build-config.js?

  1. I have tried with editor settings mentioned in comment two. This time I have changed them to
    			CKEDITOR.replace( 'editor1', {
    				extraPlugins: 'divarea',
    				enterMode : CKEDITOR.ENTER_DIV,
    				forcePasteAsPlainText : true
    			});
    
  1. I have used file attached for copying text
  2. I have pasted with Ctrl+v and with dialog in latest trunk version but result was always the same after switching to source mode.

Perhaps some other plugin is causing this or I simply don't understand steps that you perform.

Changed 6 years ago by Jakub Ś

Attachment: divs.txt added

Changed 6 years ago by Perttu Myry

Attachment: build-config.js added

comment:5 Changed 6 years ago by Perttu Myry

Sorry for the incomplete details, the steps you did to reproduce are correct. I uploaded the build-config.js we are using and did furthermore testing. I'm using Ubuntu 12.04 LTS and this issue happened when using Chrome version 26 (26.0.1410.63). Pasted data looked to be correct when using Firefox version 20.

I'm not sure whether doctype has any effect, but we are currently using strict XHTML 1.0 doctype in our system.

I will test this paste issue also using my Windows 7 laptop and report the results here soon.

Thanks for your efforts so far.

comment:6 Changed 6 years ago by Jakub Ś

Description: modified (diff)
Keywords: Webkit added
Status: pendingconfirmed
Version: 4.0 Beta

Problem can be reproduced in divarea sample in Webkit browsers from CKEditor 4.0 beta. Editor must have following settings:

CKEDITOR.replace( 'editor1', {
	extraPlugins: 'divarea',
	enterMode : CKEDITOR.ENTER_DIV,
	forcePasteAsPlainText : true				
});

Pasting with Ctrl+V and with dialog produces different results.

Last edited 6 years ago by Jakub Ś (previous) (diff)

comment:7 Changed 5 years ago by Jakub Ś

Resolution: fixed
Status: confirmedclosed

I have just checked latest CKEditor 4.3 and it seems problem doesn't occur there. Results in all browsers are consistent.

Changed 5 years ago by Perttu Myry

Attachment: build-config.2.js added

comment:8 Changed 5 years ago by Perttu Myry

I just downloaded CKEditor 4.3 with out current build-config.js which I uploaded here as an attachment (build-config.2.js). For some reason I can still reproduce the issue. I tested this on Firefox 25.0.1 and Chrome 31.0.1650.57 on Ubuntu 12.04 LTS.

In case it's of any help I can give you access to our development environment in which I'm currently experiencing this behavior.

comment:9 Changed 5 years ago by Jakub Ś

We have checked this on two independent machines. Works as expected.

Crtl+V, Paste and Paste as Plain Text work the same. The only difference is Paste From word but this is because it is used for Word and not HTML. In that later case first word filter is user and then pasteFromWordAsPlainText setting. That is why result differs in last case (this is not a bug) but all other results are consistent.

comment:10 Changed 5 years ago by Perttu Myry

Sorry, I tested this in haste and didn't clear browser cache and thus got faulty results. This issue is indeed fixed. Thanks for your patience and hard work to solve this among many other issues!

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy