Make WordPress Core

Opened 6 years ago

Closed 4 years ago

#31157 closed defect (bug) (duplicate)

TinyMCE inserts non-breaking spaces in unwanted places

Reported by: nonverbla Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.1
Component: TinyMCE Keywords:
Focuses: javascript, administration Cc:


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 ;)

Attachments (1)

Screen Shot 2015-01-28 at 14.34.23.png (92.2 KB) - added by nonverbla 6 years ago.
see the   between the word and the link?

Download all attachments as: .zip

Change History (15)

6 years ago

see the   between the word and the link?

#1 @SergeyBiryukov
6 years ago

  • Focuses ui removed

Related: #31156

#2 @pavelevap
6 years ago

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...

#3 @nonverbla
6 years ago

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);


#4 @nonverbla
6 years ago

Maybe this can be put somewhere to fix this behaviour? (I don't know how to extend the wordpress tinyMCE)

#5 follow-up: @nonverbla
6 years ago

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) {

  // stores the editor instance
  var editor = event.editor;

  // always do this when the editor looses focus
  editor.on('blur', function (event) {

    // get the contents, but get them raw! All other formats fail to return the   we are looking for
    var content = editor.getContent({format: "raw", no_events: 1});

    // now replace that sucker
    content = content.replace(/ /ig, ' ');

    //... and re-set the content
    editor.setContent( content, {no_events: 1} );


Any thoughts on this approach?

Version 3, edited 6 years ago by nonverbla (previous) (next) (diff)

This ticket was mentioned in Slack in #core by iseulde. View the logs.

6 years ago

#7 @iseulde
5 years ago

#31676 was marked as a duplicate.

#8 @iseulde
5 years ago

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

#9 @kashmiri
5 years ago

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

#10 in reply to: ↑ 5 @kashmiri
5 years ago

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!

#11 @archon810
5 years ago

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).

#12 follow-up: @archon810
4 years ago

Any updates here? It's still happening.

#13 in reply to: ↑ 12 @Dexterity
4 years ago

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.

#14 @azaozz
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

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 &nbsp; so at least the users can delete them in the Text editor.

Note: See TracTickets for help on using tickets.