Opened 6 years ago

Closed 6 years ago

#10582 closed Bug (wontfix)

Webkit: Incorrect selection endOffset for styled content

Reported by: Teresa Monahan Owned by:
Priority: Normal Milestone:
Component: General Version: 4.1.3
Keywords: IBM Cc: Satya Minnekanti, Irina

Description

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.

Change History (8)

comment:1 Changed 6 years ago by 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?

comment:2 in reply to:  1 Changed 6 years ago by 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?


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.

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

comment:4 Changed 6 years ago by Frederico Caldeira Knabben

Status: newpending

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.

comment:5 in reply to:  4 ; Changed 6 years ago by 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?

comment:6 in reply to:  5 ; Changed 6 years ago by 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.

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

comment:8 Changed 6 years ago by Frederico Caldeira Knabben

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