<br> vs \n in side a <pre>

[yuhai]

Test the issue from ​http://ckeditor.com/demo#full

1. Set config.enterMode = CKEDITOR.ENTER_BR;
2. See the differece in behavior between 2.1 and 2.2:

2.1. Type two lines content(<br> will exist), select them, click Formatted. <br> will be replaced /n in side a <pre>
2.2. Click Formatted, type two lines. <br> won't be replaced with /n in side a <pre>

How do solve the inconsistent behavior? Can we keep <br> after clicking Formatted?

Thanks in advance.

[Jakub Ś]

I can't reproduce that.

I can see result you are talking about but only when looking at HTML with e.g. Firebug. When getting data from editor with getData method or when switching to source mode (it also uses getData) the BR's are removed.

The method I'm talking about is how you should be getting data from your editor. When using traditional submit, this is being done automatically. When using AJAX application you should be using ​http://docs.ckeditor.com/#!/api/CKEDITOR.config-cfg-autoUpdateElement and ​http://docs.ckeditor.com/#!/api/CKEDITOR.editor-method-getData.

I'm closing this issue because I think it is invalid. @yuhai if there is anything I have missed, please leave a comment.

[Byran Zaugg]

yuhai's coworker here,

We are using the HTML output in a custom data processor. We use toDataFormat() to get the data and start processing it.

​http://docs.ckeditor.com/#!/api/CKEDITOR.dataProcessor-method-toDataFormat

See our code usage: ​https://github.com/liferay/liferay-portal/blob/b9dd1d7eea80d136a772b3529e954959f2611b9d/modules/frontend/frontend-js-web/src/META-INF/resources/html/js/editor/ckeditor_diffs/plugins/bbcode/bbcode_data_processor.js#L115

When I output the html argument, at this point, I see both both \n and <br> depending on whether Formatted was used after (2.1) or before (2.2) the text was inputted.

[Byran Zaugg]

I think we are focusing on the wrong issue in this ticket.

We are trying to help debug the issue by showing that the output HTML is different. But I think that's distracting them from the real issue.

The real issue is that, while editing the content, before any output/conversion (getData(), Source view, etc.). the behavior of Formatted is different, depending on whether you Formatted before or after entering text.

Do you want us to create another ticket or modify this one's description to better describe the issue?

[Piotrek Koszuliński]

I confirm that enter plugin inserts <br>s in <pre> instead of inserting new lines. I agree that this is inconsistent with what happens when the "formatted" style is applied and this can be considered as a bug.

However, I don't see it as an important issue. The CKEditor output is correct, because the data processor unifies those line breaks. Also, there's no visual difference when using new lines and <br>s, so for the user the content is identical.

I'm also afraid that there was a reason why enter key inserts <br> rather than new lines. For example - I would expect some issues related to placing selection if there are no <br>s. Perhaps it's just my paranoia, but it proved to be right many times :D.

Anyway, I'll confirm this ticket.

[Jakub Ś]

I'm not sure if you have modified source code, overwritten editor.dataProcessor or listen to editor#toDataFormat event but perhaps you could try something like: toDataFormat(editor.getData(), false); as a workaround. That way you could get optimized HTML without BR's for your data processor.

[Byran Zaugg]

We do compile from source. Thank you for the suggestion.

[Byran Zaugg]

editor.getData() didn't help us, as by that point it's too late.

I have a solution. ​https://github.com/blzaugg/liferay-ckeditor/compare/master...m-13240-toPre-br

Sorry, I'm not able to create a proper pull request. I think because we didn't fork the repo via the Github UI.

[Piotrek Koszuliński]

I've worked for a while on this, but unfortunately this patch is not enough or perhaps it's even a wrong direction.

I wrote simple tests in ​branch:t/13240. They are supposed to check what happens when pre style is applied. There should be <br>s in the resulting DOM, but even with your patch the tests fail. At the same time, I manually confirmed that your patch is good. So why the tests fail?

In order to be able to compare innerHTML of some element with a pattern we pass it through the bender.tools.prepareInnerHtmlForComparison method. It's a pretty powerful tool which can e.g. handle selection markers, so we are able to easily compare selections. However, it uses CKEDITOR.htmlParser. And it turns out that by default CKEditor's parser turns <br>s in <pre> into new lines...

Thanks to that I thought to check one thing - when you load <pre> into editor the HTML data processor produces new lines, not <br>s. So currently, the only thing which uses <br>s inside <pre> is the enter key. Both - styles system and the data processor - use new lines. So I think that changing the styles system is a wrong direction. Most likely it's enter key what should be changed.

[Byran Zaugg]

I started down the enterKey route, but soon realize I was in over my head, on what would need to change to support it there.

I think around here; maybe?: ​https://github.com/ckeditor/ckeditor-dev/blob/master/plugins/enterkey/plugin.js#L456-L460

I also wanted to treat the behavior surrounding the opening and closing <pre> more like <blockquote>. In that, Enter(new-lines) would stay inside the <pre>, while providing the red dotted line thingy to break out and start a new block (<p>).

This change works for us, but I definitely see the value in matching the output from HTML data processor.