Webkit: Incorrect selection endOffset for styled content

[Teresa Monahan]

To reproduce:

• Open any CKEditor sample in Chrome or Safari.
• Clear all editor contents and then insert the following in source view:

  <p><strong>www.sampleurl.com</strong></p>
  

• Switch back to wysiwyg mode and run the following in the browser console:

CKEDITOR.instances.editor1.getSelection().getRanges()[0]

Problem: The endOffset of the selection is 18, but there are only 17 characters in the editor.

This only occurs when the text has some styling applied (bold, font, size etc). In FF and IE, the endOffset is 17 as expected.

[Piotrek Koszuliński]

Hmm... I tried to reproduce this issue on Chrome, but I always get endOffset == 17. However, I had to move selection manually to the end, because by default it is at 0 position. I tried selecting using mouse, CTRL+A and right arrow - I only was able to reach endOffset == 17.

Are you sure that you described all required steps?

• Chrome version 28.0.1500.52
• Tested on ​git:a609ec5

[Teresa Monahan]

Replying to Reinmar:

Hmm... I tried to reproduce this issue on Chrome, but I always get endOffset == 17. However, I had to move selection manually to the end, because by default it is at 0 position. I tried selecting using mouse, CTRL+A and right arrow - I only was able to reach endOffset == 17.

Are you sure that you described all required steps?

• Chrome version 28.0.1500.52
• Tested on ​git:a609ec5

Sorry, this does seem to be intermittent with the steps I provided. A more reliable testcase is to type the url manually in the editor:

• Clear all editor contents.
• Apply bold styling by clicking the toolbar button or using Ctrl+B
• Type 'www.sampleurl.com'
• Inspect the selection by running CKEDITOR.instances.editor1.getSelection().getRanges()[0] in the browser console.
  

I am using the same git version as you and Chrome 28.0.1500.63.

[Piotrek Koszuliński]

Now I see it. Thanks.

This is caused by the filling char which is created on Webkits when selection is set inside empty inline elements (see #1272). The filling char is invisible (it's a zero-width space), but it's there, so offset==18 is correct, although I'm not sure whether it shouldn't be removed after we start typing.

[Frederico Caldeira Knabben]

It would be important for us to have a real world test case for this issue, which makes the problem more tangible.

CKEditor certainly do DOM manipulation for several different needs and things like the filling-char are totally acceptable. As long as they don't bring an issue to the end user, we should not spend much time on this.

Therefore, please bring us more information about the severity of this issue and its reason why.

[Teresa Monahan]

Replying to fredck:

It would be important for us to have a real world test case for this issue, which makes the problem more tangible.

CKEditor certainly do DOM manipulation for several different needs and things like the filling-char are totally acceptable. As long as they don't bring an issue to the end user, we should not spend much time on this.

Therefore, please bring us more information about the severity of this issue and its reason why.

Hi, thanks for the information on this. The usecase that we have is that we are relying on the selection to automatically convert urls to anchor nodes in the editor. This selection issue in Webkit means that the url does not get detected and therefore an anchor does not get created. Is there any way to detect the presence of this filling character in the editor?
Could this issue also be causing the problems reported in tickets #8332, #8620, #8554 and #8669?

[Frederico Caldeira Knabben]

Replying to tmonahan: Is there any way to detect the presence of this filling character in the editor?

When testing the contents for links, you may remove the \u200B, which is the filling char.

Could this issue also be causing the problems reported in tickets #8332, #8620, #8554 and #8669?

It's hard to say. It looks like those tickets are connected to the filling char, but more research is required for each case.

[Teresa Monahan]

Replying to fredck:

When testing the contents for links, you may remove the \u200B, which is the filling char.

Great, thanks Fred! We will try this as a workaround for the issue.