Opened 5 years ago

Last modified 17 months ago

#11415 review Bug

[Chrome]   is inserted instead of space.

Reported by: Piotr Jasiun Owned by: Tade0
Priority: Nice to have (we want to work on it) Milestone:
Component: General Version: 4.6.2
Keywords: Webkit Blink Cc:

Description (last modified by Jakub Ś)

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 "&nbsp;".

In FF everything is fine.

Probably related: #10359 and #9998

Change History (26)

comment:1 Changed 5 years ago by Piotr Jasiun

Summary: [Chrome]&nbsp; instead of space before link[Chrome] &nbsp; instead of space before link

comment:2 Changed 5 years ago by Marek Lewandowski

Status: newconfirmed

confirmed but i belive there is already ticket for that somewhere

comment:3 Changed 5 years ago by Piotr Jasiun

Description: modified (diff)

comment:4 Changed 5 years ago by Jakub Ś

Keywords: Webkit Blink added
Version: 3.6.6 (SVN - trunk)3.0

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.

comment:5 Changed 4 years ago by 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.

comment:6 Changed 4 years ago by 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.

Last edited 4 years ago by Frank Farm (previous) (diff)

comment:7 Changed 4 years ago by Jakub Ś

Description: modified (diff)

comment:8 Changed 4 years ago by Jakub Ś

Description: modified (diff)
Summary: [Chrome] &nbsp; instead of space before link[Chrome] &nbsp; is inserted instead of space.

comment:9 Changed 4 years ago by 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.

comment:10 Changed 3 years ago by Lyuba

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

comment:11 Changed 2 years ago by Jakub Ś

#14718 and #14379 were marked as duplicates.

comment:12 Changed 2 years ago by 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?

comment:13 Changed 2 years ago by Marek Lewandowski

Milestone: CKEditor 4.6.0

comment:14 Changed 2 years ago by Tade0

Owner: set to Tade0
Status: confirmedassigned

comment:15 Changed 2 years ago by 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.

comment:16 Changed 2 years ago by 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)
...

comment:17 Changed 2 years ago by 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.

comment:18 Changed 2 years ago by 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.

comment:19 Changed 2 years ago by Tade0

Status: assignedreview

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.

comment:20 Changed 2 years ago by Marek Lewandowski

Milestone: CKEditor 4.6.0CKEditor 4.6.1

comment:21 Changed 2 years ago by Marek Lewandowski

Milestone: CKEditor 4.6.1CKEditor 4.6.2

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

comment:22 Changed 2 years ago by Marek Lewandowski

Milestone: CKEditor 4.6.2
Priority: NormalNice to have (we want to work on it)

Moving to the nice to have list.

comment:23 Changed 22 months ago by 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!

comment:24 Changed 21 months ago by gnomon

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

comment:25 Changed 18 months ago by Stan

Version: 3.04.6.2

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

Last edited 18 months ago by Stan (previous) (diff)

comment:26 Changed 17 months ago by 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.

Note: See TracTickets for help on using tickets.
© 2003 – 2017 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy