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

[Chrome] The macOS accent panel places inserted characters far after initial selection #4307

Closed
f1ames opened this issue Mar 9, 2018 · 3 comments · Fixed by ckeditor/ckeditor5-engine#1424
Labels
package:engine type:bug This issue reports a buggy (incorrect) behavior.
Milestone

Comments

@f1ames
Copy link
Contributor

f1ames commented Mar 9, 2018

Extracted from https://github.com/ckeditor/ckeditor5-typing/issues/95 as I found an exact cause and it deserves a separate issue as it is quite different than others.

The issue:
mar-29-2017 19-13-56

As mentioned in https://github.com/ckeditor/ckeditor5-typing/issues/95#issuecomment-371516735, this issue is caused by the native Chrome bug which moves the selection if some characters are removed from focused text node (while triggered by listening on event like keyup, compostion*, etc).

The issue was reported here - https://bugs.chromium.org/p/chromium/issues/detail?id=820067 and has been partially solved in Chrome 65 (just in time as it was released few day ago) 🎉 However, for this case it still happens (see above report for more detials).


The real problem with it, is that usually we may block removing inlineFiller during composition, however in this case keyup is fired before compositionstart (so renderer is unaware of composition which may/will take place) and removes the inlineFiller as character was already inserted, which triggers the native issue moving caret / inserting character in a wrong place.

@f1ames
Copy link
Contributor Author

f1ames commented Mar 9, 2018

It could be solved by inserting/keeping fillers when selection is on element boundary (as mentioned in #4303).

@f1ames
Copy link
Contributor Author

f1ames commented Mar 13, 2018

The native Chrome issue was closed as WontFix, but as mentioned in a previous comment it should be solved by further improvements in fillers managment.

@f1ames
Copy link
Contributor Author

f1ames commented Apr 17, 2018

It is not only case of inline filler unfortunately. When working on #3703 I noticed following behaviour - when some text is inserted or removed from before selection (via CharacterData.insertData/deleteData) in the text node in which composition takes place, the accent character is placed in the offset from selection equal to inserted/deleted characters (it happens only if no accent was selected before text length changes):

collab1 chrome

Reinmar referenced this issue in ckeditor/ckeditor5-engine Jun 18, 2018
Fix: Renderer should avoid doing unnecessary DOM structure changes. Ensuring that the DOM gets updated less frequently fixes many issues with text composition. Closes #1417. Closes #1409. Closes #1349. Closes #1334. Closes #898. Closes ckeditor/ckeditor5-typing#129. Closes ckeditor/ckeditor5-typing#89. Closes #1427.
@mlewand mlewand transferred this issue from ckeditor/ckeditor5-engine Oct 9, 2019
@mlewand mlewand added this to the iteration 18 milestone Oct 9, 2019
@mlewand mlewand added status:confirmed type:bug This issue reports a buggy (incorrect) behavior. package:engine labels Oct 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
package:engine type:bug This issue reports a buggy (incorrect) behavior.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants