In FireFox68.01 or later, if you start a new line with [Shift] + [Enter] and enter multibyte characters from the beginning after the line feed, the original characters disappear.

[pdc-dev]

Type of report

Bug

Provide detailed reproduction steps (if any)

1. Use [Shift] + [Enter] to start a new line in the middle of the string. (Example) abcdefghijklmnopqrstuvwxyz ↓ abcdefg([Shift] + [Enter] will start a new line) hijklmnopqrstuvwxyz

2. Enter multiple multibyte characters from the beginning of the new line (Example) abcdefg (Enter multiple multi-byte characters here) [９９９９９] hijklmnopqrstuvwxyz

Expected result

The multibyte character entered before the original string is inserted (Example) abcdefg ９９９９９hijklmnopqrstuvwxyz

Actual result

If you enter multiple multibyte characters after a line feed, the original string will be deleted (Example) abcdefg ９９９９９wxyz

Other details

• Browser: FireFox68.01以降
• CKEditor version: 4.12.1

[Comandeer]

I can't reproduce the issue. Do you use IME to add the characters at the beginning of the newline? If yes, can you provide info about your operating system?

[pdc-dev]

Thank you for contacting us. Use Japanese IME to add characters to the beginning of a line break. The operating system is windows7 and windows10.

Thank you.

[Comandeer]

I can confirm that the issue is present when IME is used.

[pdc-dev]

Thank you for confirmation. Are you planning to fix this issue?If yes, when will it be completed? Thank you.

[f1ames]

I have added this issue to the next iteration (which starts on the beginning of October). However, before investigating, it's hard to tell how hard it will be to fix and how much time we may need.

[msamsel]

It looks that the problem doesn't occur in Firefox 70. I used this version: https://www.mozilla.org/en-US/firefox/70.0beta/releasenotes/ This version should become stable on 22nd October. I'll still inspect the issue, however, if the fix would be too heavy, then we could just wait, as there won't be any CKE4 release before 22 October.

[msamsel]

I've investigated the case, unfortunately without luck. Case somehow seems to be related to a keyboard event but listening before an after it processing in the editor looks correctly. However, adding asynchronous check after 100ms after the change, show that editor's content change. I also inspect when and how are used setText method. Also, check when the native element is obtained by defining a getter for $ Thos showed that the latter node is not touched by CKEDITOR. Mutation observe also doesn't provide much information with that case. Unfortunately, I wasn't able to reproduce the issue in native contenteditable to have 100% sure that is a browser issue. Spending more time on issue investigation seems to be unnecessary, as it is going to be fixed with the next FF release.

@pdc-dev can you check if the issue is not reproducible in newer Firefox version (v70)?

[pdc-dev]

I confirmed that the problem was not reproduced in Firefox 70. Thank you for the survey. I am very grateful to you.