[Chrome]   is inserted instead of space.

[Piotr Jasiun]

This ticket looks like continuation of #9929. The problem is that #9929 was fixed in CKE 4.2.3 but it seems it has reappeared again in CKE 4.4.1

Besides below TC with link you can also reproduce this problem with:

1. Paste below in source mode and switch to wysiwyg.

   <p>This is a simple sentence.</p>
   

2. Remove space with backspace or delete and then insert it again. Result:

   <p>This&nbsp;is&nbsp;a&nbsp;simple&nbsp;sentence.</p>
   

---

1. Open editor (replacebyclass.html) and inset following html in source mode:

   <p>Source: <a href="http://en.wikipedia.org/">Wikipedia.org</a></p>
   

2. Switch back to WYSIWYG mode.
3. Put cursor just before 'Wikipedia.org'.
4. Press backspace.
5. Press space.
6. Go to source mode.

Result: You will see:

<p>Source:&nbsp;<a href="http://en.wikipedia.org/">Wikipedia.org</a></p>

Expected: There should be " " instead of " ".

In FF everything is fine.

Probably related: #10359 and #9998

[Marek Lewandowski]

confirmed but i belive there is already ticket for that somewhere

[Jakub Ś]

Problem can be reproduced from CKEditor 3.0 win Webkit and Blink browsers.

This ticket is a continuation of #9929. We have fixed raw text problems but not text plus some element.

[Frank Farm]

This problem also happens with source code

<p>foo bar</p>

then return to wysiwyg mode, delete the space, then press space to obtain

<p>foo&nbsp;bar</p>

In other words, it does not occur only adjacent to an anchor element.

[Frank Farm]

This problem also happens in CKEditor 4.4.3 (Standard) (revision fd4f17c) currently at ​http://ckeditor.com/demo in Google Chrome 36.0.1985.143 on Mac 10.9.4. However, the problem does not appear with Firefox 30.0 and 31.0 on Mac 10.9.4.

[Frank Farm]

This problem also happens with source code

<p>foo bar</p>

then return to wysiwyg mode, select "bar", copy, place the cursor before the f in "foo", paste, press Spacebar, switch to source mode to obtain

<p>bar&nbsp;foo bar</p>

Happens in CKEditor 4.4.5 (Standard) (revision 25cdcad) currently at ​http://ckeditor.com/demo in Google Chrome 38.0.2125.104 on OS 10.9.5.

The same problem does not occur in Firefox 31.0 on OS 10.9.5.

In other words, the problem also occurs when pressing Spacebar directly after a paste.

[Lyuba]

Hi, this problem is still happening in the current release (just checked on ​http://ckeditor.com/demo). Any hopes in getting it fixed?

[Jakub Ś]

#14718 and #14379 were marked as duplicates.

[Jason Malatia]

This needs to be fixed! ckEditor is not use-able for Windows Chrome as it puts in &nbsp; every time you try and edit anything. I reported this bug 7 months ago on Ticket#14379 ​http://dev.ckeditor.com/ticket/14379. Chrome for Windows is the most popular browser and I don't understand why it hasn't been fixed yet?

[Tade0]

I found that when the user presses backspace, a newline character is inserted where the space character was a moment ago.

The same behaviour does not occur in a raw, native contenteditable element.

[Tade0]

The precise point where the newline insertion happens is here: ​https://github.com/ckeditor/ckeditor-dev/blob/10377f5c07798160a8840eacda4ffa745cc3c03d/core/dom/range.js#L1152

Call stack:

checkStartOfBlock (range.js:2345)
mergeBlocksCollapsedSelection (editable.js:2349)
...

[Tade0]

After an extensive exercise in archeology I found the reason why range.trim() was put in range.checkStartOfBlock() in the first place.

Judging by what I know now the solution to the problem described in this ticket would be to make range.checkStartOfBlock() non-destructive and this is what I am planning to do.

This is also a perfect opportunity to document what this method does.

[Jason Malatia]

Tade0 wrote, when the user presses backspace the issue occurs... the same result happens when the delete key is pressed to as well.

[Tade0]

Summary of the reasons for this bug and the solution.

Problem: range.checkStartOfBlock() splits the text node at which a collapsed selection is anchored when pressing backspace/delete. This later forces the editor to produce a non-breaking space at that point.

The way range.checkStartOfBlock() and range.checkEndOfBlock() work is validated by the following tests: ​http://tests.ckeditor.dev:1030/tests/core/dom/range/blockindication

From which one can notice that the former returns true for: <p> ^Test </p> - this result is achieved by using range.trim().

---

Starting with #3367 CKEDITOR.dom.walker was calling range.trim() so to prevent it from making changes while walking the same method was preemptively called in range.checkStartOfBlock().

Starting with #8632 CKEDITOR.dom.walker stopped calling range.trim() but the same change was not made in range.checkStartOfBlock(), so it remained destructive.

---

The changes I've made basically simulate the same split mentioned earlier, but without touching the DOM. From now on both range.checkStartOfBlock() and range.checkEndOfBlock() do not make any changes in the DOM.

Tested on Chrome, Firefox, IE11 using both backspace and delete.

Changes pushed to ​branch:t/11415.

[Marek Lewandowski]

Moving to 4.6.2 minor release, as 4.6.1 is mostly about polishing 4.6.0.

[Marek Lewandowski]

Moving to the nice to have list.

[gnomon]

I cannot see why Priority was changed to "Nice to have" here. I think the &nbsp; bug is simply unacceptable and must not be considered as "to be dealt with" by the CKEditor users confronted with this bug! And, this bug has been there for such a long time now, be it as reappearing or not!

[gnomon]

IF one is working within the Chrome browser, this really is a considerable problem!

[Stan]

I think when first time is space and then nbsp, then its ok.

[Jakub Ś]

From what I have checked, first issue is no longer reproducible in Chrome but it is still reproducible in Safari. Second issue is reproducible in both browsers.