Opened 12 years ago

Closed 12 years ago

#8328 closed Bug (wontfix)

CKEDITOR not consequent when entering something after a link

Reported by: Henrik Helmø Larsen Owned by:
Priority: Normal Milestone:
Component: General Version:
Keywords: Cc:


The editor is not consequent when entering something after a link. Sometimes the entered character becomes part of the link - sometimes it becomes the first letter of the node following the link!

In FireFox (6.0.1) it seems like it is doing it correct. When moving the cursor towards the end of the link (using arrow keys) and stopping after the last character of the link and pressing the "A" character on the keyboard, the "A" becomes part of the link (it will now be the last character in the link). When the cursor is moved towards the link from "after the link" and stopping just before the last character of the link and then pressing "A" on the keyboard the "A" will NOT become part of the link but instead it will become the first letter after the link. When the same is done using CTRL+V (copying content from the clipboard) it works in the same way. This I believe is the correct behavior :-)

When using Chrome (13.0.782.215 m) it it a different matter: When doing the same procedure as explained above, it is not possible to enter "A" as the last character in the link - no matter from witch direction your cursor is coming from, it always inserts the "A" after the link. Oppositely when entering something via the clipboard (CTRL + V) it always becomes part of the link - in this case it is not possible to paste something in just after the link! The behavior of Chrome - I believe - is not correct and is not consequent!

IE (9.0.8112.16421) also behaves strange! When entering an "A" via the keyboard after the link it is always inserted after the link no matter how the cursor arrived to its position. When entering something via the clipboard (CTRL + V) it is also always inserted after the link.

You could argue that IE is consequent - but it would be nice for all browsers to behave the same way.

I have encountered this problem because my links should not be editable - so whenever a character is pressed while the cursor is inside a link the event is ignored/canceled. It is though allowed to edit text right next to the link ;-)

All of the above is tested using the latest nightly build (

I use Windows 7 Ultimate SP1

Change History (1)

comment:1 Changed 12 years ago by Jakub Ś

Resolution: wontfix
Status: newclosed

I have stumbled once on this issue -

Look at comment no. 4. Especially this part:

Now, back to the difference... some browsers, especially Firefox, make it easy to move in and out element boundaries, while others, especially IE, doesn't provide this feature at all.

In Firefox, there are two options when you move the mouse to the boundaries of an element:

If you were inside the element, you'll remain inside of it. (like <b>text</b>) If you were outside the element, you'll remain outside of it. (like <b>text</b>)

What you have described is behavior controlled by a browser. What is more it is default browser behavior (even MS word works that way) which only Firefox breaks out of.

I'm sorry but there is nothing we can do fix it.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy