Opened 6 years ago

Last modified 6 years ago

#13575 assigned Bug

IE11: Typing in Korean with Enter Mode BR moves cursor to previous line.

Reported by: Jakub Ś Owned by: Szymon Cofalik
Priority: Normal Milestone:
Component: UI : Enter Key Version: 4.0
Keywords: IE11 Support Cc:

Description (last modified by Szymon Cofalik)

  1. Load EnterKey sample
  2. Click inside editor Set Korean language and Hangul keyboard (Korean character (not Latin))
  3. Reload the page and change enter mode to BR
  4. Click at the end of line and press Enter
  5. Start typing

Result: Cursor will be moved up

Problem can be reproduced in IE11 only at least from CKEditor 4.0.

Issues which may be related: #10414, #12910

Edit: This is IE11 bug, it was reported here

Attachments (2)

2015-07-24_1321.swf (735.7 KB) - added by Jakub Ś 6 years ago.
video showing the problem
korean.png (2.3 KB) - added by Jakub Ś 6 years ago.

Download all attachments as: .zip

Change History (12)

comment:1 Changed 6 years ago by Jakub Ś

NOTE: I'm pressing 'G' and 'I' on Latin keyboard after pressing Enter. After pressing 'I', cursor moves to previous line.

Changed 6 years ago by Jakub Ś

Attachment: 2015-07-24_1321.swf added

video showing the problem

Changed 6 years ago by Jakub Ś

Attachment: korean.png added

comment:2 Changed 6 years ago by Piotrek Koszuliński

It's a weird issue. I can imagine such bug on Chrome and Safari, but not on IE11. We don't do anything special while user is typing so I don't know why the composition would be broken. I'm curious if it happens in a native content editable as well...

comment:3 Changed 6 years ago by Wiktor Walc

Sometimes although the cursor moves up, after typing letters the text is written correctly back in the correct line (d enter f g f). A working combination of letters that can be used to completely reproduce the issue (write in line "N" and have another letter written in line "N-1") is: enter f g j k

comment:4 Changed 6 years ago by Wiktor Walc

@Reinmar: plain contenteditable works just like CKEditor with <p> enter mode.

Version 0, edited 6 years ago by Wiktor Walc (next)

comment:5 Changed 6 years ago by Wiktor Walc

Status: newconfirmed

comment:6 Changed 6 years ago by Szymon Cofalik

Owner: set to Szymon Cofalik
Status: confirmedassigned

comment:7 Changed 6 years ago by Szymon Cofalik

This is IE bug (also it happens in ENTER P mode if you just use shift+enter). Open plain contenteditable but use shift+enter instead enter. Then IE won't insert <p> but <br />. In this scenario, bug is reproducible. Also weird things happen (both in CKEditor and plain contenteditable) after caret is put in previous line (햐 is GI):

1) If you hit shift+enter, caret is moved to the third line, below the original 햐:

Foo bar.^<br />


Foo bar.<br />
햐<br />

2) If you type something else, extra characters are inserted:

Foo bar.^<br />

type 햐, becomes

Foo bar.햫햐햐^<br />

3) If you hit backspace you get a sign that represents G.

4) However when you change keyboard to other language (win+space), the caret gets back to correct position.

It looks like caret is rendered a line above but it acts like it is partially in line above but partially in line below.

The bug does not occur on Edge.

Last edited 6 years ago by Szymon Cofalik (previous) (diff)

comment:8 Changed 6 years ago by Szymon Cofalik

We could try to fix it by appending ZWS when composition start and the previous node before current selection is <br />. Sounds good in theory but I don't know if it is possible without generating additional problems.

Anyway, when I pasted ZWS before writing 햐 it worked like charm.

comment:9 Changed 6 years ago by Wiktor Walc

oh, forgot to test shift+enter on plain contenteditable, good catch.

comment:10 Changed 6 years ago by Szymon Cofalik

Description: modified (diff)
Note: See TracTickets for help on using tickets.
© 2003 – 2021 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy