Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#13701 closed Bug (invalid)

Indent copied text

Reported by: Irina Owned by:
Priority: Normal Milestone:
Component: General Version:
Keywords: IBM Cc: Satya Minnekanti, giogio, inga, Christophe Guillou


Steps to reproduce

  1. Open an external program, like note pad, and type a few lines like:
  1. Copy the text
  2. Paste into the ckeditor with DIV enter mode (either by using the paste text dialog, or by ctrl + v)
  3. Put your cursor at the beginning of the second line of text
  4. Hit the indent toolbar button

Expected result

only second line of text is indented

Actual result

all three lines of text are indented

Other details (browser, OS, CKEditor version, installed plugins)

It looks like this issue occurs because all three lines are part of one DIV block, and the line breaks are achieved via <br> tags. Shouldn't separate lines be in separate DIV blocks instead? It looks like ckeditor interprets single line breaks as <br> and double line breaks as separate <DIV>s when pasting, is it expected?

Change History (5)

comment:1 Changed 9 years ago by Jakub Ś

Resolution: invalid
Status: newclosed
Version: 4.5.2

This is an old question and we had it asked few times before. Let me explain it again.

One enter in notepad (line under line) means br will be used to split them
Two enters in notepad (line of text, empty line, line of text) means P/DIV will be used to split lines.
IIRC this unified behaviour was introduced in CKEditor 4.x.

Please see attached file and paste separate samples of text to see different results.

comment:2 Changed 9 years ago by Irina

Thanks for your feedback, this is much appreciated. Could you provide some more details on why this behaviour was introduced in CKEditor 4.x, perhaps some documentation?

comment:3 Changed 9 years ago by Jakub Ś

I'm not sure if there is any documentation for it however I remember exactly that we had few bug reports about pasting from note pad and different outcome in browsers. We decided to unify this behaviour. Now it should work the same in all browsers.

comment:4 Changed 9 years ago by Christophe Guillou

One of our key customers reached us for the same query as Irina - stating that the behaviour introduced in CKEditor 4.x is causing them a lot of issues, and is errorneous. I personally do not believe that there is an actual issue to be concerned with, but as Irina suggested in her previous comment, we'd like to be able to indicate our customers that the change was made in support of a new feature. So if can confirm that this was introduced in relation of Notepad / IIRC, that would be a good step forward - is there a logged ticket / feature request in CKSource that we can use as backup doc?

Thanks for your help

comment:5 Changed 9 years ago by Piotrek Koszuliński

I think that this change may not have any ticket, because it was part of early works on CKEditor 4 and at that moment we used an internal issue tracker.

Prior to CKEditor 4 there was no special filter for pasting plain text. That meant that whatever the browser generated for that plain text it was inserted into the editor. However, Chrome, Firefox and IEs work differently – one creates divs, second paragraphs and the third <br>s. I'm not sure now what happened with that HTML later on, upon insertion into the editable, but exactly that was a reason why we changed all this - we wanted to have control and knowledge what happens.

Therefore, many things were changed in the clipboard implementation and in the editor.insertHtml. To of them are significant for this case:

  1. In one of editor#paste listeners we implemented a heuristic which detects whether a content was pasted from a plain text editor. If so, we call the htmlifiedTextHtmlification() function (you can find in the clipboard plugin) which normalises that HTML like j.swiderski described in comment:1. Later on, in CKEditor 4.5 in some browsers we started accessing the clipboard directly, so we can now get the real plain text instead of HTML which the browser generated for it. But the result is the same as editable.transformPlainTextToHtml() outputs the same as htmlifiedTextHtmlification().
  2. Prior to CKEditor 4, the editor.insertHtml() used the browser's native command to insert HTML into the editable. In CKEditor 4 we wrote this algorithm ourselves what fixed many issues and incompatibilities between browsers.

So, if you want to override the default behaviour you can simply add a listener to editor#paste with a priority <6 (e.g. 5) and:

  • if there's something in 'text/plain' ), transform that plain text into HTML of your choice,
  • if browser does not support the clipboard API, take the HTML in and transform it into HTML of your choice.

One more thing – you wrote that this is confusing right now. It's only confusing if it's not apparent to the user what a paragraph is and what a line break is. This may happen if you have no margins between paragraphs. Please also note that the user may insert a <br> using Shift+Enter (unless CKE was configured differently), so the same situation may happen without any pasting.

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