TinyMCE inserts non-breaking spaces in unwanted places

[nonverbla]

My first bug report, so please bear with me...

In TinyMCE, if I add a link to a word and then remove the space before this link and then press space, there is a non-breaking space ( ) inserted. This breaks the layout in many cases because it prevents the text from wrapping as it expected. Tested on a clean install.

Maybe it is ment to be a feature of some kind, but for me it behaves like a bug ;)

[nonverbla]

see the   between the word and the link?

[SergeyBiryukov]

Related: #31156

[pavelevap]

Yes, I noticed the same problem. In my case it is related to using CTRL-X and CTRL-V shortcuts, for example when moving sentences or changing strong tags. But I was not able to find out exact steps to reproduce, it is sort of random behaviour, first observed several years ago...

[nonverbla]

a quick workaround until this is solved (of course less then ideal, since all the nbsp; stay in the database)

function remove_nonbreakin_spaces($string) {
	// the non-breaking space character, got you!
	// http://www.utf8-chartable.de/unicode-utf8-table.pl?start=128&number=128&utf8=string-literal&unicodeinhtml=hex
	return str_replace("\xc2\xa0", " ", $string);
}
add_filter('the_excerpt', 'remove_nonbreakin_spaces', 99);
add_filter('the_content', 'remove_nonbreakin_spaces', 99);

:

[nonverbla]

Maybe this can be put somewhere to fix this behaviour? (I don't know how to extend the wordpress tinyMCE)
​https://processwire.com/talk/topic/5297-undesirable-two-typed-spaces-become-spacenbsp/

[nonverbla]

so... I think I found a real work-around for this. I put this script after the tinymce script, using the 'after_wp_tiny_mce' action hook:

tinymce.on('AddEditor', function(event) {

  var editor = event.editor;

  editor.on('getContent', function (e) {

    var content = editor.getContent({format: "raw", no_events: 1});
    e.content = content.replace(/ /ig, ' ');
    
  });

});

Any thoughts on this approach?

[iseulde]

#31676 was marked as a duplicate.

[iseulde]

#31676: In Chrome, selecting some text to edit creates a new text node, which is padded with  .

[kashmiri]

Same here, confirmed in Chrome on all WP versions up to and including 4.3.1.

[kashmiri]

Replying to nonverbla:

so... I think I found a real work-around for this. I put this script after the tinymce script, using the 'after_wp_tiny_mce' action hook:

tinymce.on('AddEditor', function(event) {

  var editor = event.editor;

  editor.on('getContent', function (e) {

    var content = editor.getContent({format: "raw", no_events: 1});
    e.content = content.replace(/ /ig, ' ');
    
  });

});

Any thoughts on this approach?

It it working for you? Would you be able to add a browser sniffer (for Chrome) and, perhaps, list the entire code including hooks for novices like me? Thanks!

[archon810]

This should be resolved properly. nbsps all over the place seemingly totally at random, and it constantly destroys the layout when the sentence jumps to the next line prematurely.

For example, a random edit I just did on a post published today.

I don't want to just blindly replace nbsps - there could be legitimate uses for them (>1 space, or writing about nbsps as part of the text).

[archon810]

Any updates here? It's still happening.

[Dexterity]

I'm still encountering this bug as well. The characters get inserted when switching from the editor's visual interface to the plain text interface and back again.

This bug also affects page builders that use the editor interface, randomly sprinkling \xc2\xa0 characters in the post's metadata, which get interpreted as   characters by the browser when the page is rendered.

Please fix this. It's been an issue in WordPress for many years.

[azaozz]

This is not new, see #26842. It is the browsers that insert these U+00A0 which is the UTF-8 for   in contentEditable. And what's worse: different browsers are inserting them at different places.

Generally they all add them to keep consecutive spaces. You know that white space doesn't matter in HTML unless it is in a <pre> tag, so when the user types several spaces in contentEditable, the browsers use a "hack" to keep all of them visible, i.e. insert U+00A0 chars.

Lately some browsers are more aggressive and also insert these chars at seemingly random places. Seems Chrome is worst, in some cases it inserts tons of U+00A0 all over.

So the short answer is: this is not a bug, this is a feature in your browser :)

The longer answer is: there is not much we can do to fix this behavior. We can of course replace all U+00A0 that don't make much sense, but we have no way of knowing if the user inserted them there on purpose or if the browser did it behind the scenes. So replacing them will introduce bugs and edge cases.

Closing this as duplicate of #26842. The best case is if this behavior is fixed/improved in the browsers, although it has existed for many years and seems to be getting worse. We can work on exposing the   so at least the users can delete them in the Text editor.