Content editor messes up my content

Question

I'm using a content editor webpart on a page. When we edit our content SharePoint adds extra <br>, #160; (non-breaking spaces), and #8203 (zero-width spaces) all over the page. This generally messes up the page and causes all kinds of things to look correctly.

It is also a problem with rich text fields on edit forms and wiki pages. Basically everywhere that a user might edit "html"-ishy text.

This seems to have been reported and annoyed people for a long time:

• This from 2013
• This from 2010
• This from 2016
• This from 2017
• This from 2011
• and on and on and on

Most answers I've found are "there is nothing you can do about it." Several others say, "That is not a bug." And a few show ways to use javascript/jQuery to remove the offending characters.

For example, in 2017 I was facing this issue in new/edit forms for a SharePoint 2013 list. I posted this question and didn't get any responses. A couple weeks later I was able to work out a solution, so we know that it isn't true that there is "nothing" that can be done.

function PreSaveAction(){
  // remove all the zero width spaces ​ from the fields.

  $('.ms-rtestate-field div[contenteditable=true]').each(function(index,element)  {
       var exp = new RegExp(String.fromCharCode(8203),"g");
       var editor= $(element);
       var txt = editor.html()
           txt = txt.replace(exp,'');
           txt = txt.replace(/ /g,' ')
           txt = txt.replace(/ {2,}/g,' ');
       editor.html(txt);
  });

  return true;
}

I also think it is ridiculous to say that these issues aren't a bug. Not really interested in debating it whether it should be called a bug or not. Whether it is a bug or not isn't the point. SharePoint shouldn't be messing up my text, period.

The few solutions I've found, like mine and a couple others, remove the extra characters either before they get save into the page or prevent them from rendering on the page and messing everything up.

I'd like to find a more proactive solution. I assume that the common point for all these issues is somehow stemming from _layouts/15/sp.ui.rte.js which contains the rich text editor code. I've been looking at the 27,000+ lines of the debug version of that and figuring out some stuff.

I see that the non-breaking and zero-width spaces are being used in some way to keep track of editing or something. Evidently there is some way that those markers being added by the code aren't being properly removed.

I can't figure out why the <br> (or sometimes <br/>) are getting added to my content. I do notice that is is partially when I click into the body of text, if the insertion point is either immediately before or after a closing element tag it seems to add the break tag. But it also adds them just to the end of my markup even if I don't select anything or click in the editor. I can't quite figure out why it is creating it, but it seems like it might be similar to the others -- using it to track or make something work, but then not properly removing it.

That is about as far as I've been able to figure out.

I'm a only a site collection admin, so I can't can't change anything from the back end or change settings in central admin. I can only make changes to client-side code.

I'd like to find some way to patch or or override methods in the sp.ui.rte.js file so that it cleans up after itself properly and quits breaking or text -- whether it is content editor, rich text field, or wiki page. And regardless of whether the text is pasted in, typed and markedup with the rich text editor controls, or manipulated in edit-source view.

Does anybody have any ideas?

Answer 1

Same Problem here. The SharePoint 2013 Update July 2019 solved the problem for us.

It contains an updated SP.UI.Rte.js (06/12/2019).

PS: The classic editor parts of SharePoint 2019 has the ZWSP bug too. The modern pages editor part has no ZWSP problem. We replaced the SP.UI.Rte.js and SP.UI.Rte.debug.js of SharePoint 2019 with the versions of the SharePoint 2013 July Update and the ZWSP bug is also gone in SharePoint 2019.

Greetings Joerg

Answer 2

I am facing a similar issue in SharePoint 2013 on-premise. I dig in into the issue and found interesting results.

1. The position of the cursor matters. When you click on edit source and you place your HTML content inside, if your cursor is placed at the end of text line or end of HTML content then a BR tag will automatically be added.
2. This behavior could especially be seen in the chrome browser. Firefox doesn't seem to be affected.
3. The position of the cursor somehow effects the sharepoint file sp.ui.rte.debug.js. It is present in _layouts/15 folder. This file has a function called $CP_0: function RTE_Range$$CP_0($p0, $p1, $p2). Inside this function we make a call to SP.UI.UIUtility.insertBefore($p0, $v_1) . Here one of the parameter is $v_1. This variable contains the br tag which gets appended. Although I am not sure why this happens only in Chrome browsers (My guess is it has something to do with canvas?)
4. You can try to debug the file and fix the issue or you can simply put the mouse cursor anywhere but in the EOL. Another option could be to manually add a script to strip off the br tag manually us JS.

I hope this helps someone in need facing similar issue.

EDIT: I found another way to deal with this problem. Just comment the below line of code in SP.UI.RTE.Debug.Js file in 15 hive Layout folder:

 // if ($p0.startcontainer.nodetype === 1 && rte.rteutility.$n($p0.startcontainer) && $p0.startcontainer === $p0.endcontainer && $p0.startoffset === $p0.endoffset && $p0.endoffset === $p0.endcontainer.childnodes.length) {
      // var $v_3 = $p0.endcontainer.ownerdocument.createelement('br');

     // $p0.endcontainer.appendchild($v_3);
 // }