Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Safari] The first line of each paragraph cannot be input into Chinese #1333

Closed
gongzhiq opened this issue Nov 1, 2018 · 22 comments
Closed
Labels
browser:safari domain:typing/ime This issue reports a problem with standard typing & IME (typing method for CJK languages). resolution:resolved This issue was already resolved (e.g. by another ticket). type:bug This issue reports a buggy (incorrect) behavior.

Comments

@gongzhiq
Copy link

gongzhiq commented Nov 1, 2018

Is this a bug report or feature request? (choose one)

🐞 Bug report

The first line of each paragraph cannot be input into Chinese.

💻 Version of CKEditor

ckeditor5 v11.1.1 classic editor build (latest version)

📋 Steps to reproduce

small6

use Safari Browser
Edition 12.0.1 (13606.2.104.1.2)

@Reinmar Reinmar added the type:bug This issue reports a buggy (incorrect) behavior. label Nov 1, 2018
@gongzhiq
Copy link
Author

gongzhiq commented Nov 1, 2018

Hello, when can I repair it? @Reinmar

@Reinmar
Copy link
Member

Reinmar commented Nov 5, 2018

Hi! Which input mode (language and keyboard) do you use precisely?

I've been able to reproduce some very weird issues with "Pinyin - Simplified" but only in Safari (it worked fine in Chrome). Do you confirm this?

Hello, when can I repair it? @Reinmar

Those are very complicated issues and I can't even tell you where to start debugging it.

@Reinmar Reinmar mentioned this issue Nov 5, 2018
@Reinmar Reinmar added this to the unknown milestone Nov 5, 2018
@gongzhiq
Copy link
Author

gongzhiq commented Nov 6, 2018

Hello! Yes, there will be a problem at the beginning of each line in simplified Chinese.

small7

@Reinmar Reinmar modified the milestones: unknown, backlog Nov 6, 2018
@gongzhiq
Copy link
Author

gongzhiq commented Nov 7, 2018

Hello, @Reinmar ,I know how to solve this problem, but I don't know how to modify the code.

Listening for input events in text input boxes triggers input events when spelling Chinese characters (input method) but Chinese characters are not actually filled into text boxes (selected words), as shown in Figure 1:

1069543-20171009211759324-6471773

Terms of settlement:After the completion of the selection, the input event is triggered, triggering only once.

1069543-20171009211830262-1175113284

var $IsInputZh = false;

editor.editing.view.document.on( 'compositionstart', function() {
	$IsInputZh = true;
} );
editor.editing.view.document.on( 'compositionend', function() {
	$IsInputZh = false;
} );
editor.editing.view.document.on( 'input', function() {
       if ($IsInputZh){
               return;
        }

     // Input content,
} );

@xinglie
Copy link

xinglie commented Nov 7, 2018

@gongzhiq I think this is a ckeditor bug , whatever use which input method . I guess ckeditor process content immediately when input event triggered.
ckeditor may process input event like native input element

@gongzhiq
Copy link
Author

gongzhiq commented Nov 7, 2018

@xinglie Yes, I think so too. It's a problem when the first paragraph of the text starts typing. It doesn't wait for the Pingyin input to complete, and then it processes the input.

@gongzhiq
Copy link
Author

gongzhiq commented Nov 7, 2018

@Reinmar Hello, this problem may be widespread. It's not only the Chinese input problem, but also the input method in other countries. I can help solve it.

@Reinmar Reinmar changed the title The first line of each paragraph cannot be input into Chinese [Safari] The first line of each paragraph cannot be input into Chinese Nov 7, 2018
@Reinmar
Copy link
Member

Reinmar commented Nov 7, 2018

I'm trying to understand one thing first – the bug was reported for Safari only. I can't reproduce any issue on other browsers (works fine in Chrome and Firefox). Nor, with other languages (checked Hiragana and Korean. Do you confirm that or are we talking about different issues?

Regarding debugging:

  1. Typing is handled by this package: https://github.com/ckeditor/ckeditor5-typing
  2. Specifically, by the Input plugin: https://github.com/ckeditor/ckeditor5-typing/blob/master/src/input.js
  3. And even more specifically by this observer: https://github.com/ckeditor/ckeditor5-typing/blob/master/src/utils/injecttypingmutationshandling.js

How it works is:

  1. It listens to mutations: https://github.com/ckeditor/ckeditor5-typing/blob/c659fa9368ad229de6fc8c4e78a6ef7b6afb4c46/src/utils/injecttypingmutationshandling.js#L20-L24
  2. When a mutation occurs it checks what changed: https://github.com/ckeditor/ckeditor5-typing/blob/c659fa9368ad229de6fc8c4e78a6ef7b6afb4c46/src/utils/injecttypingmutationshandling.js#L62-L72
  3. If it's a text insertion or replacement, the input command is executed with this data. It's executed in multiple places in that listener, but here's one example: https://github.com/ckeditor/ckeditor5-typing/blob/c659fa9368ad229de6fc8c4e78a6ef7b6afb4c46/src/utils/injecttypingmutationshandling.js#L218-L222
  4. The input command changes the model. The model is converted to the view (virtual DOM). If that view differs from the DOM (e.g. the character was inserted by the browser in an incorrect place), we re-render the DOM. We do not touch it otherwise.

Unless... we're talking about composition. Here it's far more tricky. We can't be doing step 4. during composition because touching the DOM means breaking the composition. That's most likely what happens in this case.

So what we do? We listen to composition events and don't do unsafe changes when the composition is taking place. But currently, that's just in one place: https://github.com/ckeditor/ckeditor5-typing/blob/master/src/utils/injectunsafekeystrokeshandling.js#L45

Most likely, there's some other change in the model/view which should not happen in the case that's broken for Chinese. My guess would be – the <br> filler (which is present in empty block elements ) gets removed when you type the first letter and that may break the composition.

The <br> filler rendering is handled by the renderer (https://github.com/ckeditor/ckeditor5-engine/blob/master/src/view/renderer.js) based on what the DOM converter returns (https://github.com/ckeditor/ckeditor5-engine/blob/master/src/view/domconverter.js).

Ticket regarding blocking block filler removal during composition: https://github.com/ckeditor/ckeditor5-engine/issues/1353

It'd be first good to make sure that it's the removal of that <br> what breaks the composition. Then we could think how to prevent its removal.

@gongzhiq
Copy link
Author

gongzhiq commented Nov 7, 2018

hi, @Reinmar ,Thank you very much for your answer. Yes, this question only exists in Safari.The above answer is very reasonable. Can we repair it according to the above statement?

@Reinmar
Copy link
Member

Reinmar commented Nov 7, 2018

Can we repair it according to the above statement?

Sure. But what I wrote is just the basics of this entire system, so I didn't even mention how the solution could look like. I just don't know without digging deep into this.

Anyway, the first thing to do is understanding at what stage the composition gets broken. To do that you need to debug step by step what happens in the renderer after keys are pressed.

@gongzhiq
Copy link
Author

gongzhiq commented Nov 8, 2018

hi, @Reinmar This is the change of HTML when entering.

small8

I don't know how to debug code, can I give a debug step?

@Reinmar
Copy link
Member

Reinmar commented Nov 8, 2018

@275208060
Copy link

video_2019-07-25_190749000000-000019
Enter Chinese Link Text also has this bug

@farthinker
Copy link

video_2019-07-25_190749000000-000019
Enter Chinese Link Text also has this bug

@275208060 It has been confirmed as another issue: https://github.com/ckeditor/ckeditor5-typing/issues/149

@Reinmar Reinmar added this to the next milestone Oct 22, 2019
@Reinmar
Copy link
Member

Reinmar commented Oct 22, 2019

I'm afraid that since we had to revert the patch, this issue is still present. More details here: #4533 (comment).

@Reinmar Reinmar reopened this Oct 22, 2019
@Reinmar Reinmar modified the milestones: next, nice-to-have Dec 2, 2019
@LukaszGudel
Copy link
Contributor

LukaszGudel commented Jan 11, 2021

I'm getting different results in manual tests and in editors from docs or online builder. I could not locate the difference in those editors that could cause this.

Manual tests (all-features, article or table)

  • when you type in new line or in empty table cell then first character is doubled and it's not part of the composition, so it stays after text conversion
  • same behaviour with Pinyin or Hiragana
  • happens only on Safari (v14.0.2 on macOS Big Sur)


Docs or online builder

  • https://ckeditor.com/docs/ckeditor5/latest/features/table.html
  • Default Classic Editor configuration from Online Builder
  • when you type in new line it works correctly
  • when you type in empty table cell then it breaks composition just like in the first post in this issue
  • Only in Safari (v14.0.2 on macOS Big Sur)
  • Only with Pinyin

(In first table cell I typed n i h a o [space], in second a a [space] a a [space])

@mlewand
Copy link
Contributor

mlewand commented Mar 1, 2021

#8759 was marked as a duplicate of this issue.

@yangguansen
Copy link

Does this problem had been solved?

@yangguansen
Copy link

Hello, @Reinmar ,I know how to solve this problem, but I don't know how to modify the code.

Listening for input events in text input boxes triggers input events when spelling Chinese characters (input method) but Chinese characters are not actually filled into text boxes (selected words), as shown in Figure 1:

1069543-20171009211759324-6471773

Terms of settlement:After the completion of the selection, the input event is triggered, triggering only once.

1069543-20171009211830262-1175113284

var $IsInputZh = false;

editor.editing.view.document.on( 'compositionstart', function() {
	$IsInputZh = true;
} );
editor.editing.view.document.on( 'compositionend', function() {
	$IsInputZh = false;
} );
editor.editing.view.document.on( 'input', function() {
       if ($IsInputZh){
               return;
        }

     // Input content,
} );

大哥,这个问题你解决了吗?我看官网demo上没有这个问题了

@Reinmar Reinmar added the domain:typing/ime This issue reports a problem with standard typing & IME (typing method for CJK languages). label Nov 4, 2021
@pomek pomek removed this from the nice-to-have milestone Feb 21, 2022
@Reinmar
Copy link
Member

Reinmar commented Dec 12, 2022

@ckeditor/qa-team, could you retest this issue?

@dufipl
Copy link
Contributor

dufipl commented Dec 13, 2022

@Reinmar I can't reproduce it on Safari on docs, nor manual test nor ckeditor.com website:
你好 working
Safari version: 16.0 (17614.1.25.9.10, 17614)

@Mgsy
Copy link
Member

Mgsy commented Dec 15, 2022

 I'm closing it., as it is no longer reproducible.

@Mgsy Mgsy closed this as completed Dec 15, 2022
@Reinmar Reinmar added the resolution:resolved This issue was already resolved (e.g. by another ticket). label Dec 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
browser:safari domain:typing/ime This issue reports a problem with standard typing & IME (typing method for CJK languages). resolution:resolved This issue was already resolved (e.g. by another ticket). type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
Development

No branches or pull requests