I'm unsure if this should be regarded as a bug on eZOE, or if we could implement an enhancement to account for a bug in Chrome and / or tinyMCE stack.

steps to reproduce

• Using chrome, in an eZ Publish 5.1 admin portal, edit or create a new article object
• In the Body field enter some text, select it, copy to clipboard, go to end of line, enter a space, paste, enter another space, paste again, publish
• View the article (either in front end or back end), inspect the text element.
  . You'll verify that the spaces between the pasted text have been replaced by non breakable spaces "& nbsp ;"

This could only be reproduced with chrome and seems to be related to this tinyMCE bug report.

The ill effect of this behavior is that editors won't notice that the XML saved has the special characters until some layout in the front end breaks, due to the non breakable spacing used.

I've compared the contents stored in MySQL ezcontentobject_attribute using chrome and firefox.
At a first glance, data_text seems the same.
But, if you select a different codepage (set names cp1250, for instance) instead of the default and expected utf8, you'll verify that chrome is adding some unexpected character to the content, right where the non breaking spaces show up